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

[Toshio Kuratomi]

On Wed, 2006-12-27 at 00:52 -0500, seth vidal wrote:
> On Tue, 2006-12-26 at 20:30 -0900, Jeff Spaleta wrote:
> > 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?
> 
Not for the first iteration[1].  I think we should be able to pull the
initial data from the repodata.  After that we'd want our ties into the
buildsystem to alert us to each rebuild.  The notification can trigger a
dep checking run against that package and notification to all the
dependent package maintainers.

> 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.
> 
Sounds right.

[1] Note -- I don't know how many revisions we'll get to before FC7.
The essential functions that I want to definitely see are:

* Replacement for owners.list
* Able to configure ACLs in the VCS
* Able to branch packages in the VCS
* Web front end for both read-only, anonymous access and read-write,
package owner access.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20061227/a6043e58/attachment.sig>