On Tue, Nov 12, 2019, at 3:35 PM, Stephen Gallagher wrote: > 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've been following the discussion, and this compels me to jump in. If you're installing things using RPM rather than DNF, you're bypassing the DNF database, and that's completely broken in my opinion. I've been teaching folks that you should only ever use YUM/DNF to perform package transactions, except for very special cases such as `rpm --setugids` or other very special RPM commands. I also can't (with clear conscience) start teaching folks to run createrepo_c just to install an updated RPM. (Side note: you still can't properly query the DNF database like you can with the YUM database; this is still broken from the YUM->DNF transition.) V/r, James Cassell _______________________________________________ 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
