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
packages.
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 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.
>>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
unavoidable reality.
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
