Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: > On Mon, Oct 07, 2019 at 03:20:21PM -0400, Alexander Scheel wrote: > >>> And where is the software for those containers coming from? Some >>> container registry like Docker Hub? One of the main points of >>> Modularity is to provide a trusted source of software to install >>> into containers. >> >> I never really understood this argument. Could you help me understand >> it? In what way do ursine RPMs not already do this? And more >> importantly, what benefits does Modularity bring, based on an earlier >> thread with Modularity use cases? > > I'm going to avoid the word "ursine" because I think it's more > confusing then helpful. It's all the same RPMs, after all. > > Without modularity, RPM doesn't offer a good way to choose between > different versions of the same thing. One can squash version numbers > into the name, which covers some use cases, but also becomes unwieldy > and loses the _idea_ that these things are different branches of the > same basic software. (Alex covered this, but I also think that part is present at the RPM level.) What's missing from a more Debian-style solution [1] (for instance) is a more full understanding of dependencies. We could implement "Provides:" (or something like it) and be done with it. This also could have the side affect of making package version upgrades more clean. >> - Any size reduction in modular RPMs can be made to urisine RPMs. > > Maybe. But what if it reduces functionality? Modularity allows there > to be a reduced version or a full version which can be swapped in. So does having "foo-full" and "foo-minimal" both provide "foo" :) More seriously, I think doing reduced functionality versions is usually a mistake. The general expectation of users seems to be that things work "the same" inside and outside containers. With a very few exceptions (e.g., early boot, installer, ...), I think foo-minimal is misguided and will only cause pain in the long run. Thanks, --Robbie 1: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
