Does Core have an accurate count of packages which are built against libraries from firefox?

[Jeff Spaleta]

On 12/26/06, Tom Lane <tgl at redhat.com> wrote:
> +1 --- although I suspect Jeff meant that already, ie, he was just
> using firefox as an example of a package with many dependent packages.

Its more than that, the firefox situation is extraordinary because of
the way the dependencies are handled. Something needs to be done,
which goes above and beyond the available dependency chain checking
script mechanisms that we currently have to catch what is happening
with broken packages with firefox library deps. If whatever that new
mechanism is, is a generally welcomed tool which all maintainers can
benefit from to help manage dependency coordination issues, great.

But I want to be clear, this is not a navel gazing exercise, where I
want to dream up the ideal notification tools meant to solve all
maintainer coordination problems and cure cancer. I am looking to
solve a very specific problem. We need a way to prevent undue delay in
correcting packages which are broken by firefox rebuilds (or other
packages) because of changes in the versioned directory tree location
which are currently undiscoverable from an rpm based dependency
checking perspective.  We have a situation right now where linked in
libraries are going missing on installed system and our available rpm
based depchecking scripts are not catching it. I've caught two CORE
packages now which are broken on my system in this way, as an
end-user. We have to do better, we need to find a way to detect this
broken dependancy chain situation asap in the published tree so the
community of maintainers can react without waiting for bugreports from
endusers which could come days or weeks after the breakage actually
occured. I'd be happy if there was a scriptable way to detect this and
add it to the summary of broken dep reports that go out to the lists.

-jef