----- Original Message -----
> From: "Stephen Gallagher" <sgallagh@xxxxxxxxxx>
> To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, October 7, 2019 2:59:37 PM
> Subject: Re: Modularity and the system-upgrade path
>
> On Mon, Oct 7, 2019 at 2:56 PM Simo Sorce <simo@xxxxxxxxxx> wrote:
> >
> > I have to ask,
> > given containers are so popular and can deal with any dependency
> > without conflicting with system installed binaries, should we really
> > continue with this very complicated modular design ?
> >
> > Shouldn't we go back to have default packages and then defer to
> > "containers" for applications (and their dependencies) that need to
> > deviate from system defaults for any reason ?
> >
>
> 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?
As far as I can see:
- Modularity doesn't bring parallel-installability. You'd have to support
it at the RPM level, which means ursine RPMs would support it to. [0]
- Any size reduction in modular RPMs can be made to urisine RPMs.
- Modules rely on RPMs as their source of trust and don't provide any new
trust models.
- To have container-only content (container-preferred content?) you'd need
the maintainer of the package to build separate "desktop/server" and
"container" streams. And, I'm not sure what benefit anyone will see,
that better structuring of sub-packages wouldn't give. Especially since
most modular content (build systems, eclipse, ...) aren't exactly suited
for production server containers. Application and development containers,
sure. [1]
I think, from the user and maintainer point of view, you could handle most
of the use cases of modules by:
- Spending a little time ensuring packages are divided up in a way that
better behaves with modules (to reduce the installation footprint...
say, {pkg}-man only gets installed when man is present, saving the space
on containers). I'd imagine this is a goal of the minimization team
that I've seen mentions of. But perhaps not. :)
- Focusing on guidelines for parallel installability for library
and applications versions.
But perhaps I just never understood Modularity after fighting with it
for so long in Fedora and ending up duplicating what it has undone in
the ursine world... Is there something obvious I'm missing of why
Modularity is more suited for containers than ursine RPMs?
- Alex
[0]: AFAICS, Modularity only gives you parallel availability, that is
multiple versions are available to be selected from, if the
maintainer wishes. But you can't go install the same packages at
two different versions.
[1]: My implicit assumption here is that there's very little we'd do
for container support besides divide down RPMs to make things
better for a layer's disk footprint... Most upstream projects will
either support running in containers, or they won't. I'd think
having lots of container-specific content would be a very minimal
edge case that I'm not sure is worth handling at this point in time.
To be clear, the above deals with *packages* installed inside other
container *images*, not an upstream deciding to say ship, an RPM and
a full *container image* of their own.
> _______________________________________________
> 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
>
_______________________________________________
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
