On Tue, 2006-12-26 at 20:30 -0900, Jeff Spaleta wrote:
On 12/26/06, Tom Lane <tgl(a)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.
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