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