Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2018-07-29
Date: Fri, 13 Jul 2018 19:33:59
Message-Id: CAAr7Pr_yJvCtOiyDhAV+7cXooyeNA=JVSoU-nvCYhBPnSnV+ew@mail.gmail.com
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2018-07-29 by Ulrich Mueller
1 On Fri, Jul 13, 2018 at 3:20 PM, Ulrich Mueller <ulm@g.o> wrote:
2
3 > >>>>> On Fri, 13 Jul 2018, Rich Freeman wrote:
4 >
5 > > I'd suggest refactoring this a bit. We have a couple of directories.
6 > > We need to establish the base, and then the directory name under that.
7 >
8 > > We have:
9 > > distfiles
10 > > packages
11 > > main repo
12 > > overlays
13 >
14 > > These can go under:
15 > > /var/db
16 > > /var/cache
17 > > /var/lib
18 >
19 > > You have just about every sane permutation of these as options, so I
20 > > suggest considering the two separately.
21 >
22 > > I think the pros/cons of the second question have already been hashed
23 > > out. I tend to agree with the /var/lib arguments for all but
24 > > distfiles (FHS directly gives the example of browser cache in
25 > > /var/cache, and that is very much what distfiles is).
26 >
27 > Agreed, so far.
28 >
29 > > For the directory under each I suggest a gentoo/portage parent
30 > > directory, and then a tree underneath:
31 > > .../gentoo/repos/gentoo (this is PMS)
32 > > .../gentoo/repos/myoverlay (this is PMS)
33 > > .../gentoo/packages (I'm not sure if this is PMS - move to portage if
34 > not)
35 > > .../gentoo/distfiles (I don't think this is PMS, but it is so
36 > > generic that it probably should be considered shared)
37 >
38 > Why the "gentoo" path component? That's not a package, and therefore
39 > not compliant with the FHS. (Or even worse, it actually _is_ a
40 > package, namely app-misc/gentoo.)
41 >
42 > > .../portage/edb (I think this is portage-specific)
43 > > .../portage/pkg (I think this is also portage-specific)
44 >
45 > > Stuff that is specific to portage and not specified in PMS would go in
46 > > .../portage. Stuff that is PMS-specified would go in .../gentoo.
47 >
48 > > Note that not all these directories need be under the same base. We
49 > > could have /var/lib/gentoo/repos, and /var/cache/gentoo/distfiles.
50 > > So, the base needs to be decided for each.
51 >
52 > > Finally, my list of final recommendations given this framework:
53 >
54 > > /var/lib/gentoo/repos/gentoo (I'm fine with cache here as well)
55 >
56 > Here we're at 5 path components again. I will likely vote against any
57 > proposal that would put the tree such deep in the hierarchy. And the
58 > double "gentoo" adds some extra ugliness.
59 >
60 > > /var/cache/gentoo/packages (These are package builds and are
61 > > completely reproducible.)
62 > > /var/cache/gentoo/distfiles (This is literally a network
63 > cache/mirror)
64 > > /var/cache/portage/edb (This is portage-specific,
65 > > but it can be regenerated)
66 > > /var/lib/portage/pkg (This is the must-preserve
67 > > metadata state of the system, in portage's internal format.)
68 >
69 > Why not keep this at /var/db/pkg? That's the path mentioned in PMS.
70 >
71
72 +1 to this.
73
74 We know through experience that moving PORTDIR and DISTDIR are safe
75 operations because a number of existing users point them at different
76 locations
77 and successfully use Gentoo. I want to avoid two things:
78
79 - Being FHS compatible at any cost[0]. This is IMHO, not an explicit goal.
80 We are FHS compatible when its convenient to be, and we are incompatible
81 when its expensive to fix or change.
82 - Tying easy changes with hard changes. Let not the perfect be the enemy
83 of the good! We can still move distdir and portdir (low cost, easy!) and
84 decide to make other changes later. I want to avoid the case where we
85 decide that "moving /var/db/pkg is hard, so in conclusion we will do
86 nothing." That is not a useful conclusion and there is no reason why these
87 changes must be made together[1].
88
89 [0] If this were literally the only non-FHS compatible thing we had left,
90 then I'd find that argument more compelling that we should change it to be
91 100% compatible. I remain unconvinced that this is the case today, and
92 unconvinced that being FHS compatible gains us anything useful. I'd love to
93 hear more about this though.
94 [1] Incremental change is the only real change. -- a proverb.
95
96 -A
97
98
99 >
100 > > /var/lib/portage/world (Current state - at least
101 > > something is already in the right place...)
102 >
103 > Ulrich
104 >