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
_______________________________________________
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
