On Wed, Jul 18, 2018 at 9:30 AM Ulrich Mueller <u...@gentoo.org> wrote: > > >>>>> On Wed, 18 Jul 2018, Rich Freeman wrote: > > > On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller <u...@gentoo.org> wrote: > >> 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. > > If I run eselect profile, it shows a list of pathnames like > default/linux/amd64/17.1/desktop. If that doesn't expose the "specific > file hierarchy" then I wonder what could ever qualify?
It lists profile names. The fact that our profiles are implemented using paths is an implementation detail. And you would have no idea that they're stored in /usr or /var from the output of eselect. If we modified PMS so that profiles were stored in a mysql database the current eselect output could work just fine. > Also eselect profile is a tool for convenience only, and nobody is > forced to use it. The make.profile symlink and its target are > mentioned in our documentation and users can set it manually. So is /var/lib/portage/world. Are you planning to move that to /etc? (I wouldn't object to that, actually.) Personally I think that a lot of this comes from the standpoint of a typical distro where command lines are things that should be hidden as deeply in the gnome menus as possible. But, my point is that if you want that kind of experience on Gentoo it is certainly possible insofar as profiles are concerned. > Hopefully we will keep having such users who want to understand the > inner workings, instead of being satisfied with a black box. :) > Ebuild repositories are human readable text, and we shouldn't move > them to a hidden location. There is nothing hidden about /var/lib. And I also prefer editing text files for the most part. My point is that FHS wasn't really written with Gentoo as its main target, and that is likely the reason for the bit about hiding paths. > > >> 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). > > I totally disagree here. We keep local copies of licenses for good > reasons, and storing them on our webserver is no substitute. I'm not sure what you're disagreeing with. I'm not advocating for not storing them locally. I'm just saying it could be done, and I did say that you had a fair point. > No, the argument is that we already use /var/db/pkg, and grouping > other related things with it seems natural. Perhaps we should be trying to move away from using /var/db, and not doubling down? > Apart from this (quoting the devmanual): "Gentoo does not consider > the Filesystem Hierarchy Standard to be an authoritative standard, > although much of our policy coincides with it." And the discussion so > far has shown that the FHS wasn't designed for our use case. We can > still use it as a guideline, but maybe we shouldn't jump through > hoops, only to make it completely fit. Sure, I'd agree with that, but why not use /var/lib then? Your only argument against it is based on the FHS, which you freely concede wasn't written to fit our use case. > The only thing that seems certain is that regardless of what we will > do, we cannot make everybody happy. We shouldn't take that as an > excuse to do nothing, because /usr/portage is no good solution either. Well, the one thing I like about all these proposals is that it will result in Gentoo systems with a wide mixture of locations for these things, which will guarantee that any script that hard-codes paths will break. That means that those who exercise their choice to do things in a more sane way than our defaults will probably run into less trouble... -- Rich
