Musing on binary tarballs

[Ben Hyde <bh...@gensym.com>]

Thoughts on the binary tarballs.

I too prefer shipping the entire mess with every one.  Sources
et. al.  I'd even lean toward including the .o and .a, but I
presume that would be too much for most to swallow.

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
system.

Is that impossible?

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.

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.

If there is to be a binary tarball that is smaller than the
everything then I'd prefer that it unpack into the apache-1.3
directory next to the usual source and build.

My fantasy is the build creates a set of things that form a
"pending install."  The small binary tarball (i.e. the one I
don't like) would then snapshot just that.

It is very good if the "pending install" is testable in place.

I want Ralf to do all the work so I can flame about this as a way
to vent my frustration about other projects.  Did I mention that
6 weeks now and the AlphaNT Visual C++ 5.0 is still lost in
purchasing?

I want a pony.

 - ben hyde

"To the untravelled, territory other than their own familiar
heath is invariably fascinating.  Next to love, it is the one
thing which solaces and delights.  Things new are too important
to be neglected, and mind, which is a mere reflection of sensory
impressions, succumbs to the flood of objects.  Thus lovers are
forgotten, sorrows laid aside, death hidden from view.  There is
a world of accumulated feeling back of the trite dramatic
expression--"I am going away." - Theodore Dreiser in _Sister
Carrie_

Re: Musing on binary tarballs

[Marc Slemko <ma...@worldgate.com>]

On Mon, 15 Jun 1998, Brian Behlendorf wrote:

> 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
> >system.
> >
> >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 :)

<sarcasm mode="unfair">

Sounds about as sane as the way some Linux distributions do it now.

</sarcasm>

Re: Musing on binary tarballs

[Brian Behlendorf <br...@hyperreal.org>]

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
>system.
>
>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.

Yes.

>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
clearer.

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction                                  brian@apache.org
                                                        brian@hyperreal.org