On Tue, Sep 24, 2019 at 09:13:51PM -0400, Stephen Gallagher wrote: > > Example: RHEL has two perl streams: > > > > perl:5.24 > > perl:5.26 [d] > > > > You can add a non-modular perl-Foo package into EPEL bacause EPEL magically > > adds perl:5.26 into the build root. > > > > If you add a perl-Foo module into EPEL, you won't be able to set a default > > stream, hence you won't be able to have it in the build root and therefore you > > won't be able to add a non-modular perl-Bar package that requires a perl-Foo > > module component into EPEL. > > > > The only solution would be either add perl-Bar as a module, or not add > > perl-Foo as a module. If you go the second path (i.e. no modules), it means > > you won't be able build none of the packages for the non-default streams (i.e. > > perl:5.24). > > Well, another thing to be aware of is that we want to avoid the "every > package has a separate module" situation, because that way lies > madness and combinatorial explosion. > > What would be best is if we look at this from top-down, rather than > bottom-up. (Or, put another way: let's solve the problem the user > cares about). > > Users as a general rule do not care which libraries they have. They > care that the application they want to run is available to them. > I cannot agree with most of the statements you made. Fedora users care about libraries because they are developers. Not about all of them but about many of them. About much larger number than is a number of applications Fedora provides. Hence limiting modules to applications is suboptimal. Starting with few application-centric modules and splitting out modules with librarires on user's requests is troublesome because you would end up with multiple modules providing the same or similar or incompatible packages. And you cannot just replace the old big modules with new slimmer ones because you cannot retire the old modules, you need to support them to the end of their life. Having few fat modules is also problematic because you will find out that they have common dependencies that would conflict each to other. (You know that modularity does not solve parallel installability.) Also there are technical issues in Fedora infrastructure that makes building large modules unreliable. Therefore in my opinion many smaller modules is the right way. It supports sharing packagers work and allows delivering fixes faster. But I agree that the current modularity implementation does not scale (performance- and tooling-wise) with a large amount of modules. A proper solution would be dissolve modules into RPM level so that it's native to RPM and DNF. But that's somewhat off-topic. > The point of this is to note that we want to encourage that if you > have packages that are tightly-coupled (or that are used together more > often than not), they should go into a module stream together. > Definitely. But my experience of maintaining hunderds of packages and mass rebuilding thousands of them says that a chance for coupling packages into modules is miniscule. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
