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