1 |
On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller <ulm@g.o> wrote: |
2 |
> |
3 |
> "Pertains to one specific host" doesn't seem to apply to the Gentoo |
4 |
> repository though. |
5 |
|
6 |
Sure it does. The state of the package repository on a Gentoo host |
7 |
doesn't affect any other host. |
8 |
|
9 |
Sure, that state is synced from someplace that many other hosts also |
10 |
sync from, so the state of THAT version of the repository does affect |
11 |
many hosts. |
12 |
|
13 |
However, if you do an emerge --sync on one host, and then an hour |
14 |
later do an emerge --sync on another host, the state of either local |
15 |
repository won't affect the other. |
16 |
|
17 |
When they talk about things that pertain to multiple hosts they're |
18 |
talking about situations where a single path is often mounted across |
19 |
many hosts simultaneously, eg using NFS. An example of this given in |
20 |
FHS is /var/mail. |
21 |
|
22 |
Now, you could share the repository across multiple hosts, but that is |
23 |
not a typical configuration. Really, just about anything on the |
24 |
filesystem could potentially be shared across multiple hosts. |
25 |
|
26 |
> Also, there is that strange requirement that the |
27 |
> file hierarchy must not be exposed to users. At least for the |
28 |
> make.profile link we rely on a well defined hierarchy, and certainly |
29 |
> expose it to users. |
30 |
|
31 |
That isn't true at all. When you run eselect profile you have no idea |
32 |
what it is looking at. |
33 |
|
34 |
The fact that some of our users like to poke around the internals of |
35 |
the package manager doesn't change the fact that it has interfaces |
36 |
that don't require direct modification. |
37 |
|
38 |
> The same is true for license information in |
39 |
> /usr/portage/licenses. |
40 |
|
41 |
You have a fair point there. Honestly, I don't really see this as a |
42 |
good reason on its own to abandon /var/lib, which is where other |
43 |
distros seem to stick stuff like this. Also, you don't need to poke |
44 |
around that directory to determine what license a package uses - just |
45 |
to read the text of the license itself (which could arguably just be |
46 |
stored on our webserver unless we're actually redistributing something |
47 |
in the repository under that license, which is unlikely in general |
48 |
since patches/etc are probably fair use). |
49 |
|
50 |
> This follows the existing usage in eselect-repositories. Note that |
51 |
> /var/db is not specified by the FHS (though it is mentioned in a |
52 |
> footnote [1]) but used by all current BSD variants. Plus, we already |
53 |
> have /var/db/pkgs and (as pointed out by antarus) we won't get rid of |
54 |
> it anytime soon. |
55 |
|
56 |
So, you reject one path on the basis of small conflicts with FHS, and |
57 |
then just toss FHS out the window entirely to use a path not specified |
58 |
at all? |
59 |
|
60 |
If you want to appeal to what BSD is doing then /usr/portage belongs |
61 |
right where it is today. Oh, and most of our packages should be |
62 |
installing to /usr/local as well. |
63 |
|
64 |
What other linux distro even has /var/db at all? |
65 |
|
66 |
> /usr/portage/packages -> /var/db/binpkgs |
67 |
|
68 |
Why not put this in /var/cache? It is completely reproducible and |
69 |
exists to save build time. That's what a cache is. |
70 |
|
71 |
Or put it in /var/lib. Certainly your objections above don't apply to |
72 |
binpkgs. |
73 |
|
74 |
-- |
75 |
Rich |