Packaging and installation

Paul Iadonisi iadonisi at colltech.com
Tue Oct 24 12:44:48 PDT 2000


  I'll tread lightly here since it's my first post.  I've been on this
list for some time, but haven't followed it much.  It seems that today
the volume of messages has increased significantly and it turns out that
it's one area I'm passionate about -- packaging systems.

 (Hmmm... passionate... treading lightly... not too easy to do)


On Tue, Oct 24, 2000 at 12:15:30PM -0700, Nicholas Petreley wrote:
> * Erik Troan (ewt at redhat.com) [001024 08:50]:

[snip]

> > Libraries are reasonably easy as they do contain symbols. Testing to see
> > if you have a new enough build of apache is much more difficult; the filesystem
> > simply does not contain that kind of information. Trying to cruft together
> > a packaging design which gets everything from the filesystem is bound to
> > fail. There is a good reason dpkg, rpm and their predecessors use a separate
> > database to store this information.
> > 
> 
> And all someone has to do to subvert the whole system is
> to ./configure;make;make install.  Nothing goes in the
> database.  Are you saying we should stop compiling things
> on our own?  

  Not sure what you're implying here, Nick, but doing a classic
'./configure;make;make install' is not just going to violate whatever
standard is defined, but it, IMHNSO, violates best practices.  Quite
honestly, if I witnessed someone who reported to me perform such a
deed on a production system, he'd at least get a reprimand.
  Now if what's considered is a change to tools like autoconf so that
there is never a cp, mv, install, etc. command in a Makefile.in file that
by default copies to a system directory without updating some kind of
system database (and potentially blindly obliterate system files) --
then we'd be talking some sense.
  I agree with and like your ideas about allowing for flexibility, but
trying to account for possible subversions of the standard that's in
place is bound place undue hardship on distributors.

-- 
-Paul Iadonisi / Consultant / Red Hat Certified Engineer
 Collective Technologies - Managing Systems and Networks
 Team Yankee, Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets




More information about the lsb-discuss mailing list