Re: Modularity and all the things

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 25, 2019 at 12:29:23PM +0200, Brian (bex) Exelbierd wrote:
> I want to jump in on one part of this ...
> 
> On Thu, Oct 24, 2019 at 10:40 AM Igor Gnatenko <
> ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
> 
> >
> > FXX: fish 3.x is non-modular, stream 4.x exists
> > FXX+1: fish 4.x is non-modular, stream 3.x exists
> >
> > * If user wants to stay on 3.x, he needs to enable stream explicitly
> > *after* upgrade and then downgrade the package (which is actually
> > unsupported).
> > * If user wants to stay on 4.x, he needs to enable stream explicitly
> > during FXX (which is totally fine), but after upgrade he has to
> > explicitly disable it.
> >
> > Obviously you can have 3.x stream for FXX and 4.x for FXX+1, but that
> > means:
> >
> > * Maintainer has to maintain that version *twice* (modular and
> > non-modular version)
> > * Nobody can guarantee that those will be compatible
> >
> 
> Wearing my "council" headgear, I look at our mission statement and the
> default streams debate and feel like this drives to the heart of it.
> "[Modularity enables] Fedora [to create] an innovative platform for
> hardware, clouds, and containers that enables software developers and
> community members to build tailored solutions for their users."  With the
> ability to change default streams, and using Igor's example above, I could
> produce a Fedora spin that defaults to fish-4 easily.  Yes, this means that
> I, or another packagers, needs to maintain a 4 stream, and that I as the
> spin master need to ensure the components I am selecting all work together.
> 
> More simply put, I feel like we are talking about Fedora's repo as a singly
> defined "thing."  Yes, it is one repo of code, but modularity lets me "see"
> it as different versions, in many ways similarly to database views.  We
> aren't trying to define the one true Fedora, we are instead defining the
> Rawhide version of Fedora and we should probably trend toward making that
> look like the Workstation Edition (our most, aiui, popularly used output).
> Everything else can use modularity to get what they want as default, aiui.

The goal that you describe make sense. But in no way is it clear that
the approach with modules is required or even the easiest option here.

Creating a spin like you describe comes down to customizing the set of
packages. We have been doing that ... since ever. Fish is a leaf package,
so it is really not a problem to build fish4 as a parallel version to
the normal fish. Just like you can install python38 in F29 or F30 right now.
And the advantage is that with some additional work, both versions can
be co-installable, giving users flexibility.

Of course this doesn't come for free, but neither is making fish
modular free. Either way, two versions need to be maintained and built
and interactions with all other packages need to be resolved and the
maintenance burden doesn't go away.

Zbyszek
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux