On Thu, Oct 17, 2019 at 07:46:04AM +0000, Dridi Boukelmoune wrote:
I may have used yum in the past to grab and NodeJS
dependency, but actual "node" developers will certainly use tools from
the NodeJS ecosystem like npm. Your average developer doesn't sit
under a waterfall and decides that they will only use dependency from
Fedora repositories and impose themselves offline builds, they use
whatever dependency solver their usual tool chain provides.
This is currently true. I think people *would* consider and possibly
even prefer distribution packages to "whatever dependency solver their
usual tool chain provides", but only if a) all necessary packages were
available, and b) they were in recent enough versions. rpms have advantages:
1. consistent and reliable installation and uninstallation
2. works for all software types (e.g. pip is great for pure-python packages,
but when one needs to interact with graphical libraries on the system, not
3. rpms are built and tested with the same set of packages that is actually
running in the target environment.
So yeah, I think that rpms and the distribution is still a useful thing,
but people are not using them when the packages they want are not available.
But that is a bigger discussion, and I don't think it's directly
relevant to the issue at hand, see below.
So to me, a good middle ground would actually to start by
build-only dependencies. But instead of hiding them as the
anti-modularity claim, have them in a in a new set of repositories:
One packager's build-only dep is another packager's runtime dep.
And when we are at the scale of a distribution, such things change
every 5 minutes. We would be moving packages back-and-forth all the
time. I don't think this is realistic at all in Fedora. In something
like RHEL, maybe it would be possible.
(This is somewhat similar to the discussions to split into rings
a few years back: it was never possible to define what the core would
be, because everything depended on everything else, the graph is
very strongly connected.)
And besides amazing improvements when it comes to fetching metadata
thanks to zchunk, I would also like to have in general less packages
and less metadata because DNF doesn't do so well in memory-constrained
There are better solutions to this issue that are not end-user-visible.
Repo metadata size is dominated by file lists. If we cleaned this up,
we would get the same benefits (or better), without introducing any
splits of packages into groups. See
and the linked discussions.