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
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.
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
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.
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
unavoidable reality.
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
