On 18. 12. 21 19:04, Matthew Miller wrote:
On Sat, Dec 18, 2021 at 09:11:08AM +0100, Alejandro Saez Morollon wrote:
But AFAIK, only users can select a module stream, right? I mean, packages can't be build on top of a module stream so new needs of package maintainers cannot be satisfy with modules.
Packages _can_ build on top of a module stream, but only if they themselves are in other modules. Partly, this is a consequence of us deciding not to have a "default module" functionality in Fedora...
Just a note here: Even with default modular streams, non-modular packages would still only be able to be built with one modular stream -- the default one. So this isn't a consequence (not even partly) of us deciding not to have default modular streams.
...snip... So anyway, back to Go — I think that's basically the line on deciding how to package this:
A) Are multiple versions primarily for _users_ and for a few "large" (in the sense of "likely to be deployed as sole tool in a container or vm") apps, or
B) Is it important to have multiple versions to build many different packages in Fedora Linux itself?
In case A, modularity _should_ be a solution (and although I know people are despairing about the technology overall, it's still being worked on and we should figure out and fix anything that's less than ideal). In case B, it's probably best to offer parallel "compat" packages, or use one of the other "alternatives to modularity" approches people have suggested.
In my opinion, both situations are best solved with regular packages. While it is *possible* to solve A with modularity, it is not *necessary*. In fact, it is discouraged:
https://docs.fedoraproject.org/en-US/modularity/policies/#_requirements_for_...
(And while I am open to discuss whether it should be discouraged or not when we "figure things out", I would prefer if we would not recommend this approach to anyone now when we agreed alternatives SHOULD be preferred.)