On Fri, Jul 13, 2018 at 3:20 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>> On Fri, 13 Jul 2018, Rich Freeman wrote:

> I'd suggest refactoring this a bit.  We have a couple of directories.
> We need to establish the base, and then the directory name under that.

> We have:
> distfiles
> packages
> main repo
> overlays

> These can go under:
> /var/db
> /var/cache
> /var/lib

> You have just about every sane permutation of these as options, so I
> suggest considering the two separately.

> I think the pros/cons of the second question have already been hashed
> out.  I tend to agree with the /var/lib arguments for all but
> distfiles (FHS directly gives the example of browser cache in
> /var/cache, and that is very much what distfiles is).

Agreed, so far.

> For the directory under each I suggest a gentoo/portage parent
> directory, and then a tree underneath:
> .../gentoo/repos/gentoo    (this is PMS)
> .../gentoo/repos/myoverlay (this is PMS)
> .../gentoo/packages   (I'm not sure if this is PMS - move to portage if not)
> .../gentoo/distfiles      (I don't think this is PMS, but it is so
> generic that it probably should be considered shared)

Why the "gentoo" path component? That's not a package, and therefore
not compliant with the FHS. (Or even worse, it actually _is_ a
package, namely app-misc/gentoo.)

> .../portage/edb     (I think this is portage-specific)
> .../portage/pkg      (I think this is also portage-specific)

> Stuff that is specific to portage and not specified in PMS would go in
> .../portage.  Stuff that is PMS-specified would go in .../gentoo.

> Note that not all these directories need be under the same base.  We
> could have /var/lib/gentoo/repos, and /var/cache/gentoo/distfiles.
> So, the base needs to be decided for each.

> Finally, my list of final recommendations given this framework:

> /var/lib/gentoo/repos/gentoo        (I'm fine with cache here as well)

Here we're at 5 path components again. I will likely vote against any
proposal that would put the tree such deep in the hierarchy. And the
double "gentoo" adds some extra ugliness.

> /var/cache/gentoo/packages        (These are package builds and are
> completely reproducible.)
> /var/cache/gentoo/distfiles           (This is literally a network cache/mirror)
> /var/cache/portage/edb                      (This is portage-specific,
> but it can be regenerated)
> /var/lib/portage/pkg                       (This is the must-preserve
> metadata state of the system, in portage's internal format.)

Why not keep this at /var/db/pkg? That's the path mentioned in PMS.

+1 to this.

We know through experience that moving PORTDIR and DISTDIR are safe operations because a number of existing users point them at different locations
and successfully use Gentoo. I want to avoid two things:

 - Being FHS compatible at any cost[0]. This is IMHO, not an explicit goal. We are FHS compatible when its convenient to be, and we are incompatible when its expensive to fix or change.
 - Tying easy changes with hard changes. Let not the perfect be the enemy of the good! We can still move distdir and portdir (low cost, easy!) and decide to make other changes later. I want to avoid the case where we decide that "moving /var/db/pkg is hard, so in conclusion we will do nothing." That is not a useful conclusion and there is no reason why these changes must be made together[1].

[0] If this were literally the only non-FHS compatible thing we had left, then I'd find that argument more compelling that we should change it to be 100% compatible. I remain unconvinced that this is the case today, and unconvinced that being FHS compatible gains us anything useful. I'd love to hear more about this though.
[1] Incremental change is the only real change. -- a proverb.

-A
 

> /var/lib/portage/world                   (Current state - at least
> something is already in the right place...)

Ulrich