catching broken deps

Hans de Goede j.w.r.degoede at hhs.nl
Thu Oct 25 13:50:09 UTC 2007


Jesse Keating wrote:
> On Thu, 25 Oct 2007 15:29:06 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> I'm much in favor of more automated checks like this too. I would
>> even like to see them because build failures, were the packager gets
>> some method to override them (for example a list of regular
>> expressions of rpmlint messages which should be ignored by this
>> check).
>>
>> Jesse,
>>
>> Could you explain why this won't work with mutlilib?
> 
> Because of the way we do multilib generation a very long process is
> involved to re-determine with the new package set exactly what is
> multilib and if this new determination would bring in anything new
> and/or lead to broken deps.
> 

Ah, but Thorsten (and I in the release-schedule discussion) are not talking 
about doing a full check, the idea is like this:
1) What does the version of package foo currently in the repo provide?
    Lets say it provides libbar.so.1 and libbaz.so.2
2) What does the just build version provide?
    Lets say it provides libbar.so.1 and libbaz.so.3
3) Is everything provided by the version of package foo currently in the repo
    provided by the newly build version of pakcage foo?
    In our example: no, libbaz.so.2 no longer gets provided
4) If the answer to 3 is no, flag this as a warning / error
    (suggestion make it a warning to the maintainer in devel (non RC freeze) and
    make it an error in stable / frozen branches *.

You see, we (Thorsten and me) do not want to make this 100% bullet proof, we 
just want to do some cheap (in computing time) checks which should catch a > 
50% percentage of all breakages.

* Packages with this error would get a special tag and rel-eng can override 
this for things like firefox updates, etc. But normally we do not want provides 
to go away with updates to a release.

Regards,

Hans




More information about the fedora-devel-list mailing list