On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > 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? The technology allows you to do this. The policy can restrict this. Of course, this particular example can be true of a non-modular RPM too; you don't *have* to build the X-devel subpackage. > 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? > That would be a technical difference. Your statement, however, is not entirely true. You can trivially override it by using RPM instead of DNF to update it. Or you can run `createrepo_c` and then add `module_hotfix = 1` to the repo file you add to DNF. > 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.] Let's leave it at "technical differences are things where the inputs and outputs of packaging differ" and "policy is what we as Fedora have decided to allow, disallow or mandate". _______________________________________________ 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
