Recapitulate the current state of Fedora Extras and some ideas to make it better

[Christian.Iseli at licr.org]

bugs.michael at gmx.net said:
> It ought to be a warning, not another hurdle which requires packagers, who
> know their stuff, to "fight" with automated tests and questionable results.
> Even if there were a simple way to disable such tests, it makes using the
> entire package maintenance environment less comfortable.

I am trying to deal with:
 - package staying within the packaging guidelines, one of which being an
   acceptable rpmlint output
 - unwanted things being suddenly provided by unexpceted packages
 - spurious soname changes
 - get to a point where it is pretty safe to have an automated rebuild of 
   everything and be somewhat confident that the outcome is not completely 
   broken

> And: *boom*  At this point in the queue of build jobs, other packages now
> fail or cause errors, since:

>  a.) they require the results of earlier build jobs
>  b.) they depend on later build jobs to be published

Yes.  The hope is that it will only go *boom* for valid reasons.

>  c.) rpmlint at the server is not the same as packager's rpmlint ;)

Could happen, but a new rpmlint error is probably something that needs to be 
dealt with.

> Additionally, packagers need to make rpmlint shut up at the buildsys level
> when it is mistaken about the things it finds and reports.

Huh?  Can you elaborate on this ?

> Bad extra burden.

Maybe.  But I'm not so sure it's such a burden.  All of this should be 
automated.

> Unless it is fully optional and can be requested by
> packagers explicitly for a "scratch target".

Maybe that's a way to get there.

> It will create so much additional traffic that less community people will be
> able to handle it, and the important changes at the spec file level will be
> monitored by even less people.

My hope is that reference files will be more stable than the package files, so 
less traffic to monitor in the end.

> As a first step, every packager (and package submitter) ought to use rpmlint
> manually more often and run it also on the binary rpms. 

AFAIK, rpmlint is mostly useful on binary rpms.  I'd just like to automate its 
use in a useful way.

But these are just ideas.  You are welcome to dislike them and/or offer other, 
better ones.

Cheers,
					Christian