[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 thl ~]$ rpm -qp libupnp-1.4.6-1.fc7.i386.rpm --requires > 1
[thl thl ~]$ rpm -qp libupnp-1.6.0-1.fc7.i386.rpm --requires > 2
[thl thl ~]$ grep -v -f 2 1
libupnp.so.2
[thl thl ~]$ repoquery -q --whatrequires libupnp.so.2
[thl 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]