Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

[Ulrich Mueller]

>>>>> On Wed, 18 Jul 2018, Rich Freeman wrote:

> On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller <ulm@g.o> 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?

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.

> 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.

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.

>> 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.

>> 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?

No, the argument is that we already use /var/db/pkg, and grouping
other related things with it seems natural.

> 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.

As I said before, the two important parts are the move from /usr to
/var, and that distfiles and packages are moved out of the repository.

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.

> What other linux distro even has /var/db at all?

Many (most?) of those that build from source. Also, Gentoo is not only
a Linux distro.

>> /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.

*shrug* I don't have a strong opinion about this. To me, binpkgs look
less cache-like than distfiles, but more cache-like than ebuild
repositories. So /var/cache/binpkgs would work for me as well.

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.

Ulrich