Re: Modularity: The Official Complaint Thread

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

 



On Tue, Nov 12, 2019 at 12:31 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote:
>
> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
> >
> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > >
> > > As Fedora developer you have a choice to join the effort, bring your
> > > input and use cases, try and test (and revert if it doesn't work) or
> > > you can stay away from it and keep using same tools as before.
> >
> >
> > Unfortunately, this is not true. It is not possible to ignore modularity, if the
> > dependencies are modularized. It is not possible to ignore modularity, if the
> > dependents are modularized. It is not possible to ignore modularity, if the
> > packages I wish to use are modularized.
> >
> > I wish Fedora packagers and users cold "stay away". But that is currently not
> > possible. My proposal to keep all defaults as non-modular packages would make it
> > exactly so.
>
> Ursa Prime effort achieves the same goal. It removes the "viral" part
> of Modularity I think.
>

That is absolutely its purpose. If we fall short of that, it's a bug
and we will fix it as soon as possible.

> As well as policy which restricts the set of default modules, which I
> think we need to change from "FESCo approves new default modules" to
> "each request for new default module should be treated as a
> System-Wide Change".
>

I'm fine with that.

> Again I fail to see the _technical_ difference between the ursine rpm
> package and a package which was built as a part of default stream. It
> is the same rpm spec from the same dist-git sources, which is built by
> the same rpmbuild command. Thus I think it is a process/policy
> difference, which we should resolve.
>

I'll acknowledge that there may be subtle differences (such as the
different "release" tag), but none (offhand) that should have a
meaningful impact as long as other policy is in place.

> And I will support a hard block on creating new default streams, until
> it is resolved.
> (With the exception of eclipse probably, which is in a broken state
> already, and for which we need to find a solution.)

This is already in place.
_______________________________________________
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