On Sat, Mar 28, 2020 at 01:06:55PM -0700, Kevin Fenzi wrote: > On Sat, Mar 28, 2020 at 07:10:55AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > > I think the question about priority was asked because: > > When installing eln by "upgrading" from rawhide, you hardly want to go > > package by package, but instead want to do a single command to install > > everything that can be installed. That's the first time where you want > > eln packages to have priority. > > ok. It's unclear to me if there is supposed to be such a path. > I know people in these threads have suggested it, but I don't know that > the change owners want it. > > > But then rawhide moves on, and some eln packages fail to build. Then > > you still want to keep the eln stuff (and not revert to to the rawhide > > versions of everything), but install the rawhide versions if that is > > the only way to satisfy dependencies. > > Sure, if the intent is for people to have long lived installs, but thats > not what I got at all. > > > So this question is how to set up inheritance and priorities to get a > > workable system like that. (Or maybe it's supposed to work in a > > different way?) > > My understanding so far is that if you want to test it, you do a install > from it's media, test and then destroy it until next time. Hm, I'm pretty certain that there were not installation media planned. In fact, there were supposed to be no deliverables... > Or if you want to test just a single or small group of packages you pull > them and load them into your rawhide install, test, and then a update > removes them so you are back at rawhide state for the next one. > > But I could be misunderstanding, or perhaps change owners do want to > allow for longer lived installs, in which case you are right that they > would want some way to make the eln packages 'newer' than rawhide > instead of older. > > Perhaps it's time for us to add some ugly hacks to rpm and make: > > f > fc > eln > f To do just that, we wouldn't need a hack. g > f, and + > anything. But without knowing what the intended way to consume this is, discussing technical details is just idle speculation. Zbyszek _______________________________________________ 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
