catching broken deps (was: Re: Development to Official)

[Thorsten Leemhuis]

On 25.10.2007 14:07, Jesse Keating wrote:

> B) potential for broken deps.  As we see from rawhide, or even updates
> today, deps can and will break often.  Doing a full proper depcheck of
> all release + updates + potential testing updates takes a good long
> time due to having to figure out the multilib set. 

Just thinking aloud:

Depends on how you do it. The most usual case that introduces broken
deps is a update to libfoo, where the new packages ships libfoo.so.2
while the old shipped libfoo.so.1 That one can esily be catched within
seconds:

[thl at thl ~]$ rpm -qp libupnp-1.4.6-1.fc7.i386.rpm --requires > 1
[thl at thl ~]$ rpm -qp libupnp-1.6.0-1.fc7.i386.rpm --requires > 2
[thl at thl ~]$ grep -v -f 2 1
libupnp.so.2
[thl at thl ~]$ repoquery -q --whatrequires libupnp.so.2
[thl at thl ~]$ # here we would see packages that still need libupnp.so.2

Takes just a few seconds. Maybe we should tech bodhi should do such a
basic check? That would catch most errors.

Or even better would be to let the buildsys do this and similar checks
(rpmlint!) after each build and tell the maintainers if something
changed. I'd like that.

CU
knurd