Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
Date: Wed, 18 Jul 2018 12:03:01
Message-Id: CAGfcS_=JHPw7EVaSvU3nctyt0YesRUDqAKq8k+KW6eysD0Zbvw@mail.gmail.com
In Reply to: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29) by Ulrich Mueller
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

Replies