Steve Grubb <sgrubb <at> redhat.com> writes:
> OK, it took 3 builds to get libprelude squared away. Now because force-tag is
> no longer available, we have libprelude-0.9.20.2-1 in rawhide and
> libprelude-0.9.20.2-3 aimed at F-9 inclusion.
>
> Does anaconda favor packages that are part of the right release even when the
> release number is smaller?
No, it doesn't, and probably never will. EVR comparisons are used in many
places, it would be pretty stupid to make Anaconda behave specially there. What
about people doing live yum upgrades? Or even apt-get dist-upgrade? You have to
bump and rebuild the Rawhide package now too.
> Was this one of the consequences considered before implementing a mandatory
> policy?
This problem also existed (to a lesser extent, sure, but it did) before the
removal of force-tag and there's already a perfectly valid solution: you MUST
NOT bump from -1 to -3 in F9, instead, you bump from 1%{?dist} to 1%{dist}.1
(and then 1%{?dist}.2 etc.), because 1.fc10 will still be larger than 1.fc9.2.
> Whoever does that n-v-r upgrade from F-9 to F-10 report may need to take into
> account that we all have to increment release numbers which makes it real
> hard to get the upgrade path right if anaconda does not favor packages within
> its own repo.
This is impossible to "take into account", you have to make the upgrade path
work for users no matter how hard it is. There can't be any tolerance because
any error makes users end up with the wrong package, potentially causing
dependency issues or other problems. You have to bump and rebuild the Rawhide
package now. And next time do it the right way (see the paragraph above).
Removing force-tag sucks in many ways, but this isn't one of them.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
