On Wed, 2013-06-19 at 10:00 -0600, Eric Smith wrote: > On Wed, Jun 19, 2013 at 4:23 AM, Nicolas Mailhot > <nicolas.mailhot@xxxxxxxxxxx> wrote: > > You don't need a special trigger. You need your requirements to match the > > constraints declared at the rpm level, then incompatibilities will be > > caught at this level by normal distro tooling. > > How does that work? A pointer to the docs is fine; My own search > apparently hasn't turned up the right stuff. I'm not sure I'd concur with Nicolas that our mechanisms in this area are entirely sufficient. If you set up your RPM dependencies to match the actual code dependencies, then when someone submits an update for one of the dependencies that breaks the chain, the 'depcheck' AutoQA test ought to fail, and I think the 'updates-testing report' mail sent to this list should highlight the issue. But neither of those are 'enforced' mechanisms: neither would prevent the update being pushed anyway. They are both advisory. So it would still certainly be the case that this could wind up out of sync. Also, putting on my Update Nerd hat for a moment, our current setup not only *doesn't encourage* coherent Bodhi updates, it more or less *actively discourages* them. It's very difficult for packagers to edit each other's updates - even provenpackagers - though pp's can edit anyone's spec file at the drop of a hat. So if someone else submits an update for one of Eclipse's dependencies which requires Eclipse to be updated too, it's very unlikely that the Eclipse maintainers will be able to do a new Eclipse build and edit it into the same update. Even though that's how it's supposed to be: updates are supposed to be internally consistent. If A depends on B, then when B is updated in a way that breaks A, the Bodhi update should contain builds of both A and B. There should not be separate Bodhi updates for A and B. But it is actually very difficult to make this happen, given the way our permissions system and Bodhi currently work. You have to really carefully arrange things and have a very high degree of co-operation between the packagers of A and B: basically, you have to make sure someone has the necessary rights to be able to submit updates for both A and B, and no-one else ever submits updates for B, or else even that person can't fix things. It kind of stinks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
