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 so much.) 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 introducing > build-only dependencies. But instead of hiding them as the > anti-modularity claim, have them in a in a new set of repositories: > > - fedora-build > - fedora-build-debuginfo > - fedora-build-source > - updates-build > - updates-build-debuginfo > - updates-build-source 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 > environments. 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 https://bugzilla.redhat.com/show_bug.cgi?id=1619368 and the linked discussions. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
