On 12/26/06, Tom Lane <tgl@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
