[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Feature Request: Administrator Install

From: David Masterson (damaster)
Subject: RE: Feature Request: Administrator Install
Date: Wed, 6 Feb 2008 15:54:33 -0800

Warren Young <> scribbled on Wednesday, February 06, 2008 3:18 PM:

> David Masterson (damaster) wrote:
>> After I've
>> done the usual "configure; make; make install;" to install the
>> package and then remove the source code,
> Why remove the sources?  After configuration, they have all the
> information you are asking for.

Who says I'm the one making the choice?  I may simply be inheriting the
leftovers of another system administor who may have been concerned ...

> [] about saving disk space, most of the bulk in a built package
> is in the resulting binaries.  It's a pretty wasteful process, what
> with the executables duplicating what's in *.o and the convenience
> libraries, plus overhead for any static links, plus debug info... 
> So, I just say 'make clean' sometime after 'make install' when I'm
> sure the package is working and I won't need to rebuild it for any
> reason.  That keeps the size of /usr/local/src under control.

...or he may have chosen to have his source and prefix directories on
two different partitions (and then lost/crashed/reclaimed the source
partition).  Or maybe a user wanted to know how a package was
configured, but doesn't have access to the system admins build system
(or even know where or what it is!). 

> If an expanded package still takes up too much space, I "collapse" it:
> Since I can reconstitute the collapsed build directory at any time, I
> can always find out how I built any given installed package. 

But you or your successor has to go through the circuitous route of
finding where the tarball was stored (perhaps restoring it from backup
-- which might take some time), finding the config.log in it, and then
hoping that no significant changes have been made to something that
config.log doesn't capture (like the full output of 'env'), but the
package is dependent on.  Also, this method is closed to users of the
package that you installed (ie. they cannot learn how you installed
something without querying you or going through the restore themselves.

Your techniques are all well and good when they are "standard practice",
but, as you know, everyone has their own standard (as in Depot, Stow,
Reflect, sourceinstaller, Make_uninstall, and so on for installing a
package).  Administrators are a group of people that are always under a
time crunch, so setting up a "standard" for this process is often
overlooked ("don't worry about doing it right -- just do it!").  I am,
therefore, suggesting that autoconf could provide a standard for
capturing into the prefix area what was done during the build in order
to relieve the administrators of that worry.  All this really means is
having "make install" copy the "config.log" and "config.status" files to
the proper place in the install area.

David Masterson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]