> Have you considered scheduling the change in version published in each COPR > repository so it doe /not/ coincide with the release of a new version of > BIND? > > I have some hosts tied to the COPR for BIND-ESV, and some tied to BIND. I > hit a stumbling block during the last "roll over" event, and it took me a a > bit to figure out if it was due to the switch of BIND-ESV from 9.11 - > 9.16 > in the repository, or the switch from 9.16.x -> 9.16.y in the code-release. > > If we could have the version published in the BIND-ESV repository advance to > the same version which was most recently published in BIND repository (i.e. > ship 9.18.x in BIND, a couple of weeks later roll BIND-ESV to 9.18.x and > BIND to 9.20.x, and a couple of weeks later release 9.18.y and 9.20.y), then > problems with the COPR "roll over" would be a little more obvious.
Sure, that's something to consider, thanks. The Copr packages have always been provided on a best-effort basis. We try to do the right thing for the majority of users, but it is clear that there is no "one size fits all" upgrade strategy. The packaging recipes for all our RPMs are publicly available [1], plus every Copr build results in the creation of an SRPM that can be reused/tweaked to produce RPMs differently in case anyone needs that. [1] https://gitlab.isc.org/isc-packages/rpms/ -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
