RPM submission procedure

[Warren Togami]

Eric S. Raymond wrote:
>> http://www.fedora.us/wiki/RepositoryMixingProblems Due to these
>> reasons fedora.us has always said that we will not coordinate with
>> external repositories. We never have these package clashes, and our
>> package quality is on the average better. The drawback here is
>> slower package review and publication.
> 
> 
> The bigger drawback is that you don't have an extras repository at
> all! It sounds like you may be allowing unattained perfection to
> become the enemy of the good.
> 

Huh?

fedora.us is all about providing add-ons for Red Hat Linux, and now 
Fedora Core.  (Well and also now Legacy, community developed security 
backport update packages for the older distributions.)


>>>(1) Software compromised for IP reasons must be exiled to livna.org
>>>   Repository keepers must agree to comply with a ban list compiled
>>>   by Red Hat.
>>
>>It already seems to have happened.  It seems that rpm.livna.org is 
>>collaborative with a Bugzilla and QA procedure too.
> 
> 
> Good, that's a forward step.

And they seem to be using the exact same QA procedure that fedora.us uses.

>>>I doubt you'd get any pushback on these requirements.  And the cost of 
>>>QA-monitoring these repositories would undoubtedly be lower than the
>>>cost of building and maintaining one big repository of your own.  You'd
>>>win fairly big on the download costs alone.
>>
>>We respectfully disagree with this line of thinking.
> 
> 
> OK, that's your call to make and not mine.  Axel Thimm's post and
> yours come together to make it clear that I've inadvertently walked
> into the middle of a political issue.  That's not where I want to be.

Unfortunately this is true of our current situation.

> 
> What I do want is a well-defined procedure by which I can drop (for
> example) fetchmail point releases into an "official" repository and
> have them available for people to apt-get.  

apt-get may be a problem, given that there is great resistance within RH 
to including apt-get within FC.  That resistance is weakening though. 
Resistance is futile. <evil grin>

There used to be seemingly good arguments against apt... like the use of 
--nodeps (which truly was not a problem).  But now the latest apt uses 
native rpmlib, so that argument is gone.  There are also benefits like 
this (quoting Panu Matilainen):
>> I have experienced yum being EXTREMELY SLOW compared to apt when 
>> calculating a huge amount of dependencies, for example.
> 
> Indeed. Just calculating the dependencies of RH 9 -> FC 1 upgrade (no
>  actual upgrade done, all headers, pkglists etc local) on my PIII
> 500Mhz testbox takes apt: 10 seconds yum: ~50 *minutes*

http://linux.duke.edu/projects/metadata/readme.metadata
Fortunately though rpm-metadata is in the process of standardizing, and 
that will further reduce resistance to including apt since the same 
mirrors will work for apt, yum, or up2date.  The question now is if apt 
and the other clients will have it fully implemented in time for FC2 
inclusion.  HELP THEM!!!


ESR wrote:
> Things I don't care about:
> 
> * what the repository is called
> * who runs it
> * whether it takes RPMs I build or builds its own from metadata and
> tarballs that I drop there.
> 

This is good.

> Things I do care about:
> 
> * It must be generally accepted as authoritative for people running Fedora.

It is already clearly understood that fedora.us will become Fedora 
Extras at some point.

> * It must not require me to do hand-work for each release (that means 
>   it can't have an unscriptable web-only interface) 
> 
> You have to solve this problem sometime, because there are about 500,000
> developers out there with similar needs.  I'm willing to build client
> tools like the fedora-submit and bugzilla-submit scripts I've already
> done to assist the effort.
> 

My greatest concern here is that I question the efficacy of any such 
client.  I can see how a XML-RPC client can used a template based 
approach in submitting new packages within a new Bugzilla report, or 
submitting a package update to an existing Bugzilla report, but 
otherwise I don't see it being very useful.

https://bugzilla.fedora.us/show_bug.cgi?id=520
Something like how I started this Bugzilla report is one way packages 
are submitted.  Only the URL to SRPM, URL to md5sums.asc, and a short 
description about what the package does.  A tool that can do this 
reliably would save maybe 30-45 seconds.  It would easy to use that same 
tool to post updates to that package in the existing report too.  Beyond 
this what would the tool do that is useful?

In the future fedora.redhat.com will allow CVS access with ACL's for 
certain developers to apply updates directly to CVS for both tracking 
and build source purposes.  My current proposal is to do both this and 
one report per package publication for tracking the discussion necessary 
to bring each package to publication status.  The procedure for 
submission, testing, approval and publication would be similar to what 
fedora.us is currently doing, except much more automated, with a few 
approval steps by managers along the way.

Currently FC is not using any Bugzilla tracking for each 
updates-testing, and this is a bit disconcerting for the community 
developers and users alike.  This direction that we are heading will 
hopefully improve this situation.

Warren