Gentoo Archives: gentoo-dev

From: Ulrich Mueller <ulm@g.o>
To: gentoo-dev@l.g.o
Subject: [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 09:56:09
Message-Id: 23375.3755.971322.887796@a1i15.kph.uni-mainz.de
1 [Moving the thread back from -project to -dev.]
2
3 >>>>> On Fri, 13 Jul 2018, Ulrich Mueller wrote:
4
5 >>>>> On Fri, 13 Jul 2018, Rich Freeman wrote:
6 >> Well, /var/lib/<something> is 3 right there. If 5 is no good then you
7 >> only have one left. We could just make it /var/lib/repos which seems
8 >> non-compliant.
9
10 > FHS 3.0 says: "An application (or a group of inter-related
11 > applications) must use a subdirectory of /var/lib for its data".
12 > Certainly /var/lib/repos is a subdirectory of /var/lib? So why would
13 > it be non-compliant? And if it was, do we care about non-compliance at
14 > the third directory level? The important part is that we move it out
15 > of /usr, and IMHO we should care to get the /var/{lib,cache,db} part
16 > somewhat right.
17
18 In the same section 5.8.1 (emphasis is mine):
19 "This hierarchy holds state information pertaining to an application
20 or the system. State information is data that programs modify while
21 they run, and that _pertains_to_one_specific_host._ Users must never
22 need to modify files in /var/lib to configure a package's operation,
23 and _the_specific_file_hierarchy_ used to store the data _must_not_be_
24 _exposed_ to regular users."
25
26 "Pertains to one specific host" doesn't seem to apply to the Gentoo
27 repository though. Also, there is that strange requirement that the
28 file hierarchy must not be exposed to users. At least for the
29 make.profile link we rely on a well defined hierarchy, and certainly
30 expose it to users. The same is true for license information in
31 /usr/portage/licenses. So I would conclude that using /var/lib does
32 not comply with the FHS.
33
34 It was mentioned that all three directories (ebuild repository, binary
35 packages, distfiles) have some characteristics of a cache. However, I
36 think this is much more true for distfiles than for the other two,
37 which cannot be easily restored to a previous state.
38
39 I therefore suggest the following scheme:
40
41 /usr/portage -> /var/db/repos/gentoo
42
43 This follows the existing usage in eselect-repositories. Note that
44 /var/db is not specified by the FHS (though it is mentioned in a
45 footnote [1]) but used by all current BSD variants. Plus, we already
46 have /var/db/pkgs and (as pointed out by antarus) we won't get rid of
47 it anytime soon.
48
49 /usr/portage/packages -> /var/db/binpkgs
50
51 This keeps binary packages along with ebuilds. As suggested by mgorny,
52 rename the "packages" directory to "binpkgs", because it is more
53 specific and avoids confusion with "pkgs".
54
55 /usr/portage/distfiles -> /var/cache/distfiles
56
57 Omitting the "portage" subdirectory level here, as distfiles aren't
58 specific to any package manager. We could use an intermediate
59 "package-manager" directory level, but then again, it would have only
60 one single subdirectory. The FHS isn't very specific about /var/cache
61 but mentions /var/cache/fonts as an example which appears to be
62 similar.
63
64 Ulrich
65
66 [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#ftn.idm236086558032

Replies