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.
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.
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.
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.
Kevin Kofler