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 |