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

Re: catching broken deps



Jesse Keating wrote:
On Thu, 25 Oct 2007 15:29:06 +0200
Hans de Goede <j w r degoede 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


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