Re: Conversion to /package

Laurent Bercot <[email protected]> wrote:
>  And as long as package authors do not distribute their software as
> /package-only tarballs, /package loses its main benefit, i.e. reliability
> of paths.

That may be the benefit that you like the most, but there are other
benefits, and those may persuade others to convert, if we can lower
the barriers to entry.  And with greater conversion, the standard
/package paths will become more prevalent.

> If I can't hardcode, say, /package/host/gnu.org/bash/command/bash
> in software that depends on bash, because on some systems it may be
> installed as /usr/local/bin/bash or /usr/bin/bash or /bin/bash, then
> I have no particular reason to use bash the /package way.

A software developer cannot hard-code any particular path to bash,
because bash's build system supports the --prefix option and does not
discourage its use; the result is that bash can be (and is) installed
in lots of different places, and a developer of a dependent package
must cope with that.  If the bash maintainer decides to publish a
slashpackage-style tarball in parallel with the traditional tarballs,
then developers of dependent packages are no worse off.  It's just one
more entry in the (already practically infinite) list of
possibilities.

But an admin of any given system is in a different situation: if they
have the option of choosing a slashpackage or a traditional
installation, they may choose slashpackage because of easy upgrading,
removal, etc.  It doesn't matter to them that the other packages on
their system which use bash can't use a hard-coded path.  (Or, if they
use hard-coded paths anyway, the admin can just add symlinks without
losing any of the benefits of their own slashpackage installation.)

If lots of admins do this, and the bash maintainer sees that the
slashpackage tarball is downloaded much more often than the
traditional one, and that some distros perhaps also use the
slashpackage one, then he may decide to stop publishing traditional
tarballs.  In time, the /package/host/gnu.org/bash/command/bash path
could become reliable.

>  /package is not (only) a matter of personal convenience. It's a matter
> of reliability and convention - and the convention is unreliable, thus
> practically useless, if it's not shared by everyone.

But neither is is only a matter of reliability and convention.  It's
also a matter of personal convenience, and I think that convenience is
the best way to gain converts.  People will be more likely to choose
slashpackage if that choice provides an immediate benefit for them
personally.


paul