[Moving the thread back from -project to -dev.] >>>>> On Fri, 13 Jul 2018, Ulrich Mueller wrote:
>>>>> On Fri, 13 Jul 2018, Rich Freeman wrote:
>> Well, /var/lib/<something> is 3 right there. If 5 is no good then you
>> only have one left. We could just make it /var/lib/repos which seems
>> non-compliant.
> FHS 3.0 says: "An application (or a group of inter-related
> applications) must use a subdirectory of /var/lib for its data".
> Certainly /var/lib/repos is a subdirectory of /var/lib? So why would
> it be non-compliant? And if it was, do we care about non-compliance at
> the third directory level? The important part is that we move it out
> of /usr, and IMHO we should care to get the /var/{lib,cache,db} part
> somewhat right.
In the same section 5.8.1 (emphasis is mine):
"This hierarchy holds state information pertaining to an application
or the system. State information is data that programs modify while
they run, and that _pertains_to_one_specific_host._ Users must never
need to modify files in /var/lib to configure a package's operation,
and _the_specific_file_hierarchy_ used to store the data _must_not_be_
_exposed_ to regular users."
"Pertains to one specific host" doesn't seem to apply to the Gentoo
repository though. Also, there is that strange requirement that the
file hierarchy must not be exposed to users. At least for the
make.profile link we rely on a well defined hierarchy, and certainly
expose it to users. The same is true for license information in
/usr/portage/licenses. So I would conclude that using /var/lib does
not comply with the FHS.
It was mentioned that all three directories (ebuild repository, binary
packages, distfiles) have some characteristics of a cache. However, I
think this is much more true for distfiles than for the other two,
which cannot be easily restored to a previous state.
I therefore suggest the following scheme:
/usr/portage -> /var/db/repos/gentoo
This follows the existing usage in eselect-repositories. Note that
/var/db is not specified by the FHS (though it is mentioned in a
footnote [1]) but used by all current BSD variants. Plus, we already
have /var/db/pkgs and (as pointed out by antarus) we won't get rid of
it anytime soon.
/usr/portage/packages -> /var/db/binpkgs
This keeps binary packages along with ebuilds. As suggested by mgorny,
rename the "packages" directory to "binpkgs", because it is more
specific and avoids confusion with "pkgs".
/usr/portage/distfiles -> /var/cache/distfiles
Omitting the "portage" subdirectory level here, as distfiles aren't
specific to any package manager. We could use an intermediate
"package-manager" directory level, but then again, it would have only
one single subdirectory. The FHS isn't very specific about /var/cache
but mentions /var/cache/fonts as an example which appears to be
similar.
Ulrich
[1]
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#ftn.idm236086558032
pgpB26eJcfh4H.pgp
Description: PGP signature
