Following BSD inherited philosophy, i think a big improvement over other Linux distributions would be a clearer separation between system and apps (this kind of distinction exists under some form with emerge update...). To be precise, as a Linux distribution is, first of all, a Unix system, it seems reasonable to think that we could define what programs are essential part of such a system, to make what i will call the 'essential part' (this part could be adapted : X11R6 is not 'essential' for a router, for exemple). All these program would take place in usual directories as FHS recommend it. The other parts, could be installed on another FS (/usr/local, /opt, /usr/packages, whatever) in order to be clearly separated of the 'essential' core. This FS should be 'self dependant': libs, etc, docs, man,... should live in it. Such a separation, imho, as several advantages: - it limits the 'bloating' of /etc, /usr/bin /usr/lib directories (what the hell gkrellm has to be under /usr/bin ???). - we may place the 'essential' part on another disk : it make backup easier, it allow NFS sharing of only the /usr/local disk. If the / disk is dead, its replacement doesn't imply the reinstallation of all the world. - it makes the whole FS much easier to browse : to find apache, i know it is under /usr/local, that it's configuration files are under /usr/local/etc, that it's init script files are under /usr/local/etc/rc.d, and so on. I know also that /etc contains only system related file, so it is with /usr/bin... As portage is human readable format, a way to do this would be to add some environnement variable, as PREFIX, or LOCALBASE which could be set in the make.default to follow the admin prefs. These variables should be considered only for emerging ebuild considered as non 'essential' (hence the initial problem: defining what is essential).
have you tried the targets 'system' and 'world' ? `emerge system -u` updates JUST the 'system' files, while `emerge world -u` updates all the files the user installed as for the PREFIX variable, you can set the variable ROOT `env ROOT=/usr/local emerge <pkg>` (see how that works ... i remember older versions having issues ...)
It seems that not all packages even honor the ROOT or PREFIX setting...net-www/apache/apache-1.3.27-r1.ebuild seems to be an example of this. I've been a die-hard FreeBSD user (and venemous Linux hater because of RPMs) for nearly eight years until I stumbled upon Gentoo's portage system last week. Changing the *default* prefix from /usr to /usr/local or /opt for non-system packages (or at least providing a mechanism to set *and honor* it in /etc/make.conf), providing a mechanism to build tbz packages (even dependencies) without installation (seems that /var/db or /tmp could be used for "staging" dependent builds), and providing a mechanism for local ebuild mods which DO NOT require a PKG_OVERLAY directory structure (a massive waste of inodes/disk space) would make portage the KILLER Linux app, IMHO. Recent FreeBSD releases, for instance, provide for a "Makefile.local" which overrides options in the Makefile in each port directory (as well as global overrides in /usr/ports/Mk). A Gentoo equivalent might be recognizing _local or .local as a valid version "tag" (like _rc or _alpha or _pre). The "rigidity" (for newbies) of the ebuild filename and /usr/portage/profiles/categories makes PKG_OVERLAY a much more painful proposition than it needs to be for folks who want to construct a LAN buildbox with local customizations.
<snip> nearly eight years until I stumbled upon Gentoo's portage system last week. Changing the *default* prefix from /usr to /usr/local or /opt for non-system packages (or at least providing a mechanism to set *and honor* it in /etc/make.conf) </snip> this is in the works, a lot of ebuilds just need to be updated and such ... <snip> providing a mechanism to build tbz packages (even dependencies) without installation (seems that /var/db or /tmp could be used for "staging" dependent builds) </snip> this does exist already <snip> and providing a mechanism for local ebuild mods which DO NOT require a PKG_OVERLAY directory structure (a massive waste of inodes/disk space) would make portage the KILLER Linux app, IMHO. Recent FreeBSD releases, for instance, provide for a "Makefile.local" which overrides options in the Makefile in each port directory (as well as global overrides in /usr/ports/Mk). </snip> Bug 1262 (and there are other similar bugs ...)
The original bug report is a non-issue, as we have /etc/make.profile/packages to define what is "system" and not.
