Hi Stephen, On Tue, Nov 12, 2019 at 6:40 PM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > On Tue, 12 Nov 2019 at 12:26, 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. > > > > 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". > > > > 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. > > Do you view provides/requires/conflicts in an RPM spec and their > equivalent in modules to be technical or policy differences. If wrote > a policy which says I built X and X-devel but only want to ship X in > the module.. is that a policy difference or a technical one? If the > policy says I can't even install a newer X/X-devel that I built with > NEVR because modules always win and it isn't a module.. is that a > technical difference or a policy one? > > I can see where those are technical because it is built into the > technology of modules/dnf/etc and I can also see it as policy as the > 'spec' file is more about setting up policies for a package needing > certain things and including/excluding other things. > > [I am asking this because if we spend a lot of time arguing because > people think X is technical and others think it is policy.. the > argument will spiral for hundreds of messages about definitions that > people thought they agreed on and not about the change itself.] You are right, I am using the terms very loosely here. I don't really plan to have a detailed discussion on default modules in this thread, so I am hand-waiving to set the context for that discussion. What I'd like to see is a separate thread or probably better a separate document where we list all differences between ursine package and a package coming from default stream and identify which differences we want to have and which we need to restrict by the policy. And once we have this restricted policy we may recheck again, if we actually have package maintainers, who would like to use default streams under those restrictions, and what are their use cases. -- Aleksandra Fedorova bookwar _______________________________________________ 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
