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.] -- Stephen J Smoogen. _______________________________________________ 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
