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
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
Where this is not possible, compatibility libraries have to be used, but
that should be the exception rather than the rule.
>The default version of a package should NEVER depend on a
>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.
>If you really cannot fix your package to build with the default
>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