/usr -> /usr/local
"Damjan Jovanovic" <[email protected]>
| Newsgroups | gmane.comp.autopackage.devel |
|---|---|
| Message-ID | <[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. 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. 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? 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?). 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. So what do you think? Damjan Jovanovic --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected] For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]