Matthew Miller <mat...@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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to