Jesse Keating wrote:
On Thu, 25 Oct 2007 15:29:06 +0200
Hans de Goede <j.w.r.degoede@xxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
