Matthew Miller <mattdm(a)fedoraproject.org> 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