On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller <u...@gentoo.org> wrote: > > "Pertains to one specific host" doesn't seem to apply to the Gentoo > repository though.
Sure it does. The state of the package repository on a Gentoo host doesn't affect any other host. Sure, that state is synced from someplace that many other hosts also sync from, so the state of THAT version of the repository does affect many hosts. However, if you do an emerge --sync on one host, and then an hour later do an emerge --sync on another host, the state of either local repository won't affect the other. When they talk about things that pertain to multiple hosts they're talking about situations where a single path is often mounted across many hosts simultaneously, eg using NFS. An example of this given in FHS is /var/mail. Now, you could share the repository across multiple hosts, but that is not a typical configuration. Really, just about anything on the filesystem could potentially be shared across multiple hosts. > Also, there is that strange requirement that the > file hierarchy must not be exposed to users. At least for the > make.profile link we rely on a well defined hierarchy, and certainly > expose it to users. That isn't true at all. When you run eselect profile you have no idea what it is looking at. The fact that some of our users like to poke around the internals of the package manager doesn't change the fact that it has interfaces that don't require direct modification. > The same is true for license information in > /usr/portage/licenses. You have a fair point there. Honestly, I don't really see this as a good reason on its own to abandon /var/lib, which is where other distros seem to stick stuff like this. Also, you don't need to poke around that directory to determine what license a package uses - just to read the text of the license itself (which could arguably just be stored on our webserver unless we're actually redistributing something in the repository under that license, which is unlikely in general since patches/etc are probably fair use). > This follows the existing usage in eselect-repositories. Note that > /var/db is not specified by the FHS (though it is mentioned in a > footnote [1]) but used by all current BSD variants. Plus, we already > have /var/db/pkgs and (as pointed out by antarus) we won't get rid of > it anytime soon. So, you reject one path on the basis of small conflicts with FHS, and then just toss FHS out the window entirely to use a path not specified at all? If you want to appeal to what BSD is doing then /usr/portage belongs right where it is today. Oh, and most of our packages should be installing to /usr/local as well. What other linux distro even has /var/db at all? > /usr/portage/packages -> /var/db/binpkgs Why not put this in /var/cache? It is completely reproducible and exists to save build time. That's what a cache is. Or put it in /var/lib. Certainly your objections above don't apply to binpkgs. -- Rich
