Re: 1.6.0 problems with libguilereadline-v-12 and fix

[Paul Jarc]

address@hidden (Robert Uhl <address@hidden>) wrote:
> address@hidden (Paul Jarc) writes:
>> <URL:http://cr.yp.to/slashpackage.html>
>
> The problem with that is it makes utter hell out of one's PATH

Nope.  <URL:http://cr.yp.to/slashpackage/management.html>:
       Adding programs to the commands-available-to-users list means
       creating symbolic links in a central directory, /command, as
       well as in /usr/local/bin for compatibility.

> Plus you get problems with tools such as info and man expecting
> files in certain locations, so you get to play with MANPATH (and
> INFOPATH, if there is such a thing).

It does take a bit of extra work to make those things work, but I
think it's worth it.

> I like how stow does it

Stow doesn't have a global registry, so it doesn't solve the problem
of accidental name collisions.  And since all files of the same type
still get squeezed into a flat namespace (.../bin, .../lib, etc.),
collisions are more likely.  With slashpackage, package and command
names are registered so there are no collisions, and other types of
files automatically don't collide because they're in separate
namespaces (i.e., separate directories).

> Plus, it's generally as simple as:
>
>     ./configure
>     make
>     sudo make install prefix=/usr/local/stow/PACKAGE_NAME
>
> which is awfully nice.

With slashpackage, it's as simple as "package/install".

> the FHS is a nice thing, and exists for a reason.

It's well-intentioned, but it doesn't work.  Did you read
<URL:http://cr.yp.to/slashpackage/studies.html>?
The FHS says:
       1.1  Purpose

       This standard enables

          o Software to predict the location of installed files and
            directories, and

          o Users to predict the location of installed files and directories.
But this simply isn't true, as the case studies show.


paul