On 02/06/2013 11:48 AM, Michael
Schwendt wrote:
Yes, I am glad you mention it. See: https://fedoraproject.org/wiki/Updating_NSSOn Wed, 06 Feb 2013 11:01:33 -0800, Elio Maldonado wrote:The problem is that there are four packages, nspr, nss-util, nss-softokn, nss, and nspr expired sooner that the others as sometines nss takes me longer. we have two options: (1) expire all of them or (2) edit overrides to extend some so they end at the same time. Given that keeping them in buildroot-override more than needed is frowned upon I should opt for (1) if there aren't any objections. By the way, as soon as the builds make it to updates-testing they are removed from buildroot but we can't always count on good timing.There is another option: (3) prepare your upgrades with a local build using Mock and including your own local testing repo. Especially if your builds have so strict inter-dependencies that they will really require buildroot overrides in koji. and the git repo - git clone git://fedorapeople.org/~emaldonado/nssmockbuilds4fedora.git I wrote it for pre-flight tests and prevent nss updates don't break packages that depend on nss, sometimes indirectly. It's a bit crude and needs a lot of work. We are now actively working on it. It doesn't yet address the buildroot override pieces expiring to soon issues which is a manual process and only being vigilant will can do it. keeping them in buildroot-override more than needed is frowned uponAs one could see. Breaking the buildroot (for everyone) is bad. Obviously. Adding buildroot overrides that might affect other builds in unknown ways bears a risk. That's why it may be necessary to (1) expire them quickly as soon as you need more time and until the full show is ready to be built. HTH |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel