-filesystem packages (was: Re: Critpath flags on Emacs and Guile)
On Sat, 22 Oct 2016 01:24:57 +0000, Zbigniew Jędrzejewski-Szmek wrote:
Probably better to just drop the -filesystem subpackage and make all
dependent
packages co-own that dir. Those -filesystem packages are a remnant of time
before repoquery could be used to easily find all packages that use some
directory.
Unrelated.
Original repoquery is very old. And before repoquery, there have been
various scripts to query remote repositories OR even create and query an
RPMDB for all packages in Rawhide, for example. Tons of directory problems
have been found and reported without and before repoquery.
The -filesystem subpackage part of the guidelines has been enhanced
multiple times long after availability of repoquery.
IMHO the rules that recommend -filesystem packages or similar
labour-intensive solutions over simply co-owning the directory are a total
waste of package time.
The guidelines serve a simple purpose: Avoid co-owning directories as much
as possible, because packages get directory ownership and/or permissions
wrong _again and again_.
The larger a shared directory tree is, the more it makes sense to put it
into a separate -filesystem subpackage. But let two packagers create a new
package for something from scratch, and they will come up with a different
solution, such as a different set of subpackages and even different names
for the subpackages.
Even with tools like repoquery, it has not been easy for other packages to
understand subpackage concepts, such as whether and when to add an
explicit dependency on a -common subpackage. The next version upgrade,
and suddenly the packagers removed that subpackage again or filled it with
different files.
It cannot be pointed out often enough, packaging guidelines would need to
be much more detailed in order to remove all the ambiguities that are left
today. One could fill a book with many pages.
I'd like to see a move towards reducing the [sub]package number. I'd
prefer more monolithic packages for large applications, no matter whether
it would increase the install size and pull in more dependencies, but this
would need to be decide by project leadership and not individual
packagers. Dozens to hundreds of tiny packages in the KiB size range is
nuts, and almost 5000 packages in the texlive- namespace is sheer madness.