the system variable $KDEDIR by default doesn't include /usr/local, which not only keeps gentoo on the autopackage blacklist (please, not autopackage holy wars), but also does interfere with some applications intigrating with KDE (including custom written applications). It's a trvial change, and I don't see any reason NOT to do it, if it makes KDE more usable with custom applications. Also, why not remove one of the blockers to ensure that those users of autopackage can have thier package install to a non broken location?
We don't *ever* install anything into /usr/local. If you are installing custom stuff there, then adjust $KDEDIR as needed, it's your responsibility.
(In reply to comment #1) > We don't *ever* install anything into /usr/local. If you are installing > custom stuff there, then adjust $KDEDIR as needed, it's your responsibility. I don't use Gentoo, but this attitude will keep me from trying it out, and certainly from using it. Just as /etc/ld.so.conf contains /usr/local/lib, and $PATH contains /usr/local/bin in almost every distribution out there, $KDEDIR should contain /usr/local, and whatever else it takes (same goes for GNOME). I compile and install lots of software manually, and /usr/local is the place for that. As per the FHS 2.3, chapter 4: "Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr."
Exactly! I didn't have the time to look up where in the FHS it said that, but I knew it was there. So, what is the reason for not supporting this? I would very much like a rational, technical explaination for why this is something gentoo won't support. Changing it manually works *per user* but what if I want to, say, write a KDE game that installs to /usr/local? It will be broken on gentoo. This to me is very very bad. There's actualy a good deal of minor changes that gentoo would need to make to fully support this. Why does ld.so.conf contain /usr/local/lib if we're not going to support /usr/local?
(In reply to comment #3) > but what if I want to, say, write a KDE game that installs to /usr/local? It will be broken on gentoo. If you write a KDE game that installs to /usr/local than your ebuild is broken. games.eclass </snip> # This is the games eclass for standardizing the install of games ... # you better have a *good* reason why you're *not* using games.eclass # in a games ebuild export GAMES_PREFIX=${GAMES_PREFIX:-/usr/games} export GAMES_PREFIX_OPT=${GAMES_PREFIX_OPT:-/opt} export GAMES_DATADIR=${GAMES_DATADIR:-/usr/share/games} export GAMES_DATADIR_BASE=${GAMES_DATADIR_BASE:-/usr/share} # some packages auto append 'games' export GAMES_SYSCONFDIR=${GAMES_SYSCONFDIR:-/etc/games} export GAMES_STATEDIR=${GAMES_STATEDIR:-/var/games} export GAMES_LOGDIR=${GAMES_LOGDIR:-/var/log/games} export GAMES_LIBDIR=${GAMES_LIBDIR:-/usr/games/lib} export GAMES_BINDIR=${GAMES_BINDIR:-/usr/games/bin} </snip>
Can you accept the fact that there are applications outside portages control? It's a bit narrow view to expect everything being installed with ebuilds (which should indeed use games.eclass but that is not the point here). After all a distribution should help it's users solve their problems and supporting /usr/local would certainly do this. Just some scenarios where /usr/local support would be good (out of my head): A user might need a new package or a newer version of a package for which there is no ebuild yet. Just think of users that don't know how to create ebuilds or don't have that additional hour to create one. If you have binary packages with their own installer then you're unhappy because it's not free as in freedom, but more importantly you probably still want to use the software and you typically want to install it in /usr/local or sometimes are forced to install it there because the binaries contain hardcoded paths. Including /usr/local in KDEDIRS would also be orthognal design to the fact that /usr/local/bin is included in the PATH. This whole issue more or less boils down to the question whether you want to accept and life with 3rd party packages that are not included with the distro or whether you want to fight them by ignoring "traditions" like /usr/local.
> If you write a KDE game that installs to /usr/local than your ebuild is > broken. But ebuilds are Gentoo specific, and therefore, we will most definitely not see, say, Epic Games release Unreal Tournament 2007 as an ebuild. The default install location for Unreal Tournament 2004 is, in fact, /usr/local/games/ut2004/. What is the guidance for us ISVs?
