On Tue, 2006-12-26 at 20:30 -0900, Jeff Spaleta wrote: > 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. Isn't this a function of the package database some of the infrastructure folks are working on? Or, alternatively, couldn't we have it tracked from the srpm builddep relationships? here's what it sounds like to me: 1. package X gets rebuilt/updated 2. package Y has a dep/build dep relationship with package X 3. package owner of package Y gets a notice that package Y has been rebuilt/updated. none of the above is really all that hard, you'd just have to iterate the packages looking for ones that have any dep relationship with any of the packages that have been updated/rebuilt. It'd probably be best if it could be a script that we ran automatically and one that a package maintainer could run to report on any of his/her packages. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
