On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova alpha@bookwar.info wrote:
On Tue, Nov 12, 2019 at 5:10 PM Miro HronĨok mhroncok@redhat.com 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.]