On to, 17 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
You are mixing up parallel availability and parallel installability.
These aren't the same. Modularity does solve parallel availability
problem. It was never designed to solve parallel installability problem.
… 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.
I don't think it is not only reasonable to have this requirement but it
is also detrimental to the project to have the requirement that
basically doubles the amount of work volunteers have to do.
Merging the modular specfile into the non-modular branches (with a fast-
forward merge) is almost no work (it takes only seconds). If, for whatever
reason, there need to be specfile differences between the modular and the
non-modular versions, they can be handled with %if conditionals.
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.
Simply providing content of default modules in non-modular way ignores the
fact that you somehow need to be able to rebuild those packages and they
might depend in their build dependencies on packages from other modules,
including non-default streams.
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.
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
