Alexander Bokovoy wrote: > On to, 17 loka 2019, Kevin Kofler wrote: >>Building against the distribution's version of libraries instead of some >>arbitrarily picked version is pretty much the whole point of non-modular >>packages. > Right, and building against carefully chosen collection of dependencies > is the whole point of modular packages. These are just two normal > requirements that aren't contradicting each other most of the time. Building against one shared distribution version of the library foo or building against a packager-chosen module stream version of the library foo are requirements that are very much contradicting each other by definition. > Modular builds treat non-modular packages as a base environment to build > on top. Sure, maintainers of modular streams need to take care of being > non-conflicting on top of that, but sometimes the conflict is > intentional as long as it is going to cover all dependencies broken by > that. See, for example, some of scenarios in > https://lists.centos.org/pipermail/centos-devel/2019-September/017774.html Those are scenarios that are very specific to a long-term distribution such as RHEL or CentOS and do not commonly apply in Fedora. In Fedora, you would typically ship a new FreeIPA in one of 2 ways: 1. as an official update to the existing Fedora release, if it is suitably compatible for that, OR 2. in the next Fedora release, which is, at any point in time, at most 6 months away. Users who really cannot wait can get the update from a Copr. And in fact, FreeIPA in Fedora is not currently a module, as you pointed out in your mail. You would also likely not need to build against a newer krb5 than what Fedora ships. Or if you do, points 1 and 2 above also apply for krb5. That whole "too fast, too slow" thing is really an issue specific to LTS distributions and not a pressing issue for a fast-moving distribution such as Fedora at all. >>This is why building against arbitrary versions of non-leaf modules is a >>recipe for version hell. > You seem to be implying that whoever is maintaining a modular stream is > not worth to trust that they are doing some reasonable work. This is not a trust thing. No amount of "reasonable work" can prevent a module depending on libfoo-1 and a (from the user's point of view entirely unrelated) module depending on libfoo-2 from conflicting. The only "reasonable work" to do there is to package libfoo1 and libfoo2 as parallel- installable packages (one of which will probably be called just libfoo, the other the suffixed name) instead of module streams to prevent the client applications from conflicting. > Dependencies aren't arbitrary; if they were, there would be probably no > need to waste our time in working on the whole build part. Whether that > is useful to you or other subset of Fedora maintainers is not > guaranteed. However, using modular streams allows to solve problems you > cannot easily solve otherwise within the same distribution for some use > cases. This is one part of value it brings that seems to be constantly > ignored with overly negative tone. [snip] > Sure, for those things that can be installed in parallel. This is not > true for a wast amount of software, we have other means to deal with it > beyond what is being discussed in this thread. Everything can be installed in parallel if appropriately packaged. Having done the packaging tricks to allow kdelibs3-devel and kdelibs4-devel to coexist (in the same /usr prefix, something upstream did not support), I know exactly what I am talking about. (And for the next major version, kf5-*-devel, we actually got upstream to care about this, so it is parallel- installable with kdelibs3-devel and kdelibs4-devel out of the box. That is really the ideal state to reach.) Kevin Kofler _______________________________________________ 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
