httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Musing on binary tarballs
Date Tue, 16 Jun 1998 03:07:59 GMT
At 09:49 AM 6/10/98 EDT, Ben Hyde wrote:
>I'd prefer that the binary tarball require a final install step
>that moves things into the user's working directories.  That step,
>to the extent possible, should rewrite things to the user's file
>Is that impossible?

It's tough, particularly when Linux newbies like placing their executables
in /etc, their conf files in /var, and their log files in ~root.  But
that's another story I guess :)

>This final install step should check that the user's machine
>seems similar to the one the build was done on.


>It ougth to be documented what the user can discard after
>the install step.  There might be levels of that, for example
>discarding the .o and .a, discarding the entire tree.

I'd prefer not to ship with .o and .a; .so for DSO I'd be up for, though.
But yes, at the end of the install, the user should be able to throw out
the entire tree.

>It is an unalloy'd good if the binary tar ball can be described
>along these lines:  "This tape contains the result of following
>the instructions found in INSTALL thru step D with the particulars
>enumerated below.  You should proceed to do steps E and F to
>finish up."  That means that all the users walk down
>the same path, which might get tested.  The only difference
>is that some users come onto the path at later points.

Yep!  I guess that means we should forget about binary renaming, as we had
done before (and which has caused a half-dozen bug db PR's, when people
couldn't find it!)

What we need to determine then is, what does it look like at the end of
"step D" in your terms... a subdir called "bin" that things get stored in
is my current preferred option.  Just like bind.  It makes instructions


pure chewing satisfaction                        

View raw message