Dne 6.3.2018 v 21:36 Kevin Kofler napsal(a): > Nicolas Mailhot wrote: >> The “never go backwards” policy means that as soon something hits devel >> other packages can rely on your package and start adapting >> their packages on the basis of your changes. You can not pull the carpet >> from under their feet just because you changed your mind. > This is entirely orthogonal to the current monotonic EVR policy because > Epoch exists (and is used to revert to older upstream releases in Rawhide at > times, which is perfectly compliant with the current policy) and because > pure packaging changes are not covered at all (given that you can just bump > Release again when reverting them). > > The policy you would like to see does not exist at this time and would have > to be worded entirely differently. > > And additionally, I would argue the opposite: It is just impossible to do > development without sometimes trying something that may fail and thus have > to be reverted. Banning that would also contradict the Changes process (see > the contingency plans). I think that Nicolas is right. In stable version, you have to, at minimum, submit build override to propagate your library into buildroot. But in Rawhide everything goes directly into buildroot and things immediately starts to depend on it. Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
