Re: /usr -> /usr/local

On 8/19/07, Mike Hearn <[email protected]> wrote:
> > Well it's about damn time /usr/local got fixed
>
> One of the reasons we made /usr the default (or rather, why I did, I
> remember it being pretty controversial back then), is that I don't
> think /usr/local can be "fixed". The idea that /usr is where software
> goes has been around a long time and has permeated its way into many
> different programs. Finding and fixing them all is a huge job, even
> assuming the maintainers want to.

Only infrastructure-level stuff needs to support /usr/local properly,
not every single package out there. Freedesktop specs already require
support for /usr/local, and eg. Gnome has followed them for years, see
also the page I made on the wiki:
http://trac.autopackage.org/wiki/UsrLocalStatus. The biggest if not
the only problem at the moment is ld-linux.so (let's hope the GNU libc
maintainers are understanding and accept a patch).

> Given the amazing amount of effort it'd take to make /usr/local a
> first class citizen alongside /usr, I made the judgement call that it
> wasn't worth the effort. The situation hasn't changed, Linux is pretty
> much the same as it was five years ago.

A few minutes spent coding patches and a few emails aren't an amazing
amount of effort. If you know of any more infrastructure-level
software that doesn't support /usr/local properly, please put it on
that wiki page and let's talk to them.

> If you want to put a lot of effort into this, I'd go back to square
> one and try to get it right. The whole idea of having /usr vs
> /usr/local is absurd and a textbook example of how not to do namespace
> design. Even if everything put into /usr/local was respected tomorrow,
> it wouldn't solve the problem of name conflicts. Linux really should
> support having two versions of the same program installed at once, but
> doesn't, purely due to this piece of UNIX historical baggage. There
> are other problems caused by this design, but I'm preaching to the
> choir here ;)

Fixing /usr/local and working on some other solution are not mutually
exclusive, nor does fixing /usr/local matter only for autopackage.

> Every new OS designed in the past 20 years has ignored this design and
> gone its own way. BeOS did it, NeXT did it, MacOS X did it, OLPC Linux
> did it. Now mainstream Linux should drop it too.

That's not completely true. I don't know much about MacOS, but on
Windows namespace conflicts are possible: unless the software is made
to be parallel installable between versions (eg. installs into
C:\Program Files\Vendor\Application-X.Y.Z), just about anything can
conflict between versions. And almost every installer tells you
"Please remove previous versions of this application prior to
installing..." :-).

Only in recent years has Microsoft actually started with DLL manifests
and activation contexts and side-by-side installation.

Good software on Linux is already parallel installable: we have glade
glade-2 glade-3, DBus already names its configuration directory
/etc/dbus-1.

> There were originally two reasons for designing autopackage to use the
> FHS, rather than something like Thomas Leonards ZeroInstall:
>
> 1) It meant better integration *now* with desktop environments like
> GNOME and KDE
> 2) I thought ZeroInstall was too radical and that something more unixy
> like autopackage would be more easily accepted by mainstream distros
>
> (2) turned out to be completely wrong - anything other than the status
> quo was too radical, thus invalidating that reason. (1) was still a
> good reason, but it would probably have been easier to improve
> GNOME/KDE than to simply break everything else to fit UNIX.
>
> Concrete suggestion-wise, take a look at:
>
> http://live.gnome.org/PackagingAbstractionLayer

I'll read that in more detail when I get the chance.

> Are DBUS services still the in-thing? Writing one of them might be a good start.

Long live autopackage
Damjan

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]