Re: /usr -> /usr/local

2007/8/18, Damjan Jovanovic <[email protected]>:
> Hi (again :-)
>
> One thing people constantly bash autopackage for is trampling all over
> /usr, and as we are not the dominant power in the Linux world, we
> can't really blame them. The alternative to /usr is of course
> /usr/local, but it's been noted that a lot of things don't work well
> there, hence autopackage doesn't use it.

Hey. Thanks for taking the lead on this.

> Well it's about damn time /usr/local got fixed, it's the second half
> of 2007 and the state of the most elementary issues we still have in
> Linux is truly pathetic. To this end I've emailed the pkg-config list
> (http://lists.freedesktop.org/archives/pkg-config/2007-July/000208.html)
> and (AFAICT) persuaded them to accept a patch that gives pkg-config
> proper support for /usr/local.

Cool.

> The same approach was also attempted with fontconfig
> (http://lists.freedesktop.org/archives/fontconfig/2007-August/002656.html),
> however they weren't very convinced and I am not sure they're wrong,
> is it a good idea to install application-specific fonts system-wide in
> the first place?

Good question. To be honest, fonts are not a big problem since very
few programs actually install fonts.

I agree with the guy on fontconfig list that app specific fonts with
no usage outside the application should be installed app-private. But
there are occasions where a package would want to install fonts system
wide. For instance a font-only package ("hey, I made these cool free
fonts and I want to give my user an easy installation - I make an
autopackage of them!")

Autopackage should make it easy to do both cases.

> If nobody has any objections, I'd like to start a wiki page that lists
> the level of /usr/local support for commonly used applications and
> libraries (we had a page like that for Linux distributions on the old
> wiki, what happened to it?).

Definitely go for it! The only page on the new wiki on this subject is
http://trac.autopackage.org/wiki/BrokenUsrLocal

> I think we should give other upstream
> projects proper /usr/local support, thus giving distros no choice in
> the matter :-). We can get a nice snowball effect going where the more
> projects support /usr/local the more examples of /usr/local support we
> can make to persuade other projects. After we have solid enough
> support for /usr/local around, we can start installing there instead
> and improve autopackage's reputation.

This sounds like a great idea. We've tried to pursue distros in the
past and clearly that didn't work well.

-Isak

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