22.06.2012 00:01, AL13N kirjutas: > Op donderdag 21 juni 2012 22:21:52 schreef Sander Lepik: >> On Jun 21, 2012 9:10 PM, "AL13N" <[email protected]> >> >>> so, there's 2 options: >>> >>> - testing i586 with backports enabled >>> - testing x86_64 without backports enabled >>> >>> this is still 2 tests, and this is sufficient. >> Are you serious? >> I've seen bugs were i586 and x86_64 doesn't work quite the same. Every arch >> + repo must be tested separately (be it tainted or release, i'm still not >> mixing backports with updates ... until you promise to do all the testing >> here and not bother QA;)). > I see... > > however, as long as backports is installed, it could still be that due to an > update a new dependency from release is pulled, which could conflict (or not > work correctly) with some of the installed backports. Like has been said for many times now, you should not backport such packages. And about the conflicting part - well, at that point you are already on your own, at least as i see it. Backports can break updating/upgrading, we can't avoid that (and for the same reason backports should be cherry-picked, so you get as little trouble as possible). The best you can do at that point is to submit a bug about broken update and maybe (just maybe) we can submit the updated package that needs those new deps into backports too - so you can pull it from there and get over the update problem. But this should be a rare case anyway. > D. not supporting backports > > for update validation of package X (let's call it update A2): > 1. testing combination: A,C,E for arch i586 > 2. testing combination: A,C,E for arch x86_64 > > for backport validation of package X (let's call it backport B2): > No testing > > Validations required: 2 for each update > => this is how it is now And for updates it should stay like that.
-- Sander
