On to, 17 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
> On to, 17 loka 2019, Kevin Kofler wrote:
>>… which is exactly why it causes version hell.
> It does not cause version hell in a system where you cannot install
> multiple versions at the same time.
You do not necessarily do that explicitly. The conflicting versions can be
dragged in by versioned requirements in other modules, which are also
allowed by design.
> In a module stream, yaml definition for the module itself is what drives
> the choice of dependencies for individual packages at large. You can have
> a module stream that requires packages from a specific subset of streams
> of intermodular dependencies that cannot be easily reproduced with
> 'almost no work' as you claim. Individual packages might simply have no
> references to those specific version requirements at all; all setup is
> done by then MBS at the moment when you do a preparation of a build
> environment for that specific module stream build.
> Individual package specfile might simply have no details of the above
> and thus, while it technically might look not too much different from
> non-modular branch, the result of building off the modular branch might
> be vastly different.
Building against the distribution's version of libraries instead of some
arbitrarily picked version is pretty much the whole point of non-modular
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.
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
Where this is not possible, compatibility libraries have to be used,
that should be the exception rather than the rule.
>>The default version of a package should NEVER depend on a non-default
>>version of another package. That is just a recipe for version hell.
> Nope. Modules have dependencies and build dependencies between modules
> effectively create a required build environment for the packages that
> are included into modules. For cases where a top-level module default
> stream is provided for users, a particular set of specific streams
> dnf/yum implicitly enables for installation of the packages from that
> stream does not really need to be comprised out of 'default' streams for
> those modules. If it was, we would never be able to build anything
> interesting out of such modular structure.
I understand how this works, so there was no need to explain it again.
The issue is that building against an arbitrary version of a library will
also lead to a runtime dependency on that version. Now if module A needs
libfoo.so.1 and module B needs libfoo.so.2, and if those are packaged as a
libfoo module with streams libfoo-1 and libfoo-2, modules A and B conflict
and cannot be installed together.
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.
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.
>>If you really cannot fix your package to build with the
default version of
>>some other package foo, then you should package the version N you need as
>>a fooN compatibility package (where at least the runtime MUST be parallel-
>>installable with the default foo, and the -devel parts SHOULD if
>>possible), not as a module.
> There is no requirement to have every single package variant to be
> parallel-installable. It will certainly be not a requirement in future
> for quite a lot of software. A MUST requirement above is what I do not
> accept, especially for complex server solutions. It is your choice of
> words, not real requirement, not even bound to a real-life need in many
> situations in the area I'm working with.
Without that parallel installability requirement, version conflicts are an
Sure, for those things that can be installed in parallel. This
true for a wast amount of software, we have other means to deal with it
beyond what is being discussed in this thread.
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland