RPM submission procedure

[Eric S. Raymond]

Warren Togami <warren at togami.com>:
> >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.)

But I just got told twice that the Extras repository does not yet exist!
 
> >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>

Actually, I don't even care about apt per se.  I could live with yum.
 
> 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!!!

Ah, now this brings up my other issue, which is that the present RPM
Groups field is basically useless and should be replaced with a Trove
map.  Who owns the format of that field?

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

That would cover the common case where I'm doing a point release that
I want to drop in to your repository.

> 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?

What I want to do is be able to call that tool in my release scripts.

That is, I want to do with the Fedora repository what I now do for all
37 of my projects via freshmeat-submit, one of my recent projects.
Whenever I do a release, I run an upload script specific to that
project.  The upload script does a bunch of uploads, then calls
freshmeat-submit.  freshmeat-submit does an XML-RPC transaction with
freshmeat.net and posts a release announcement.

What I want to be able to do is run a client that drops submission
information in your queue automatically, mining it out of my locally
generated RPMs if need be.

You tell me the required metadata is (1) an URL to an SRPM, an MD5
signature, and a package description.  This raises a couple of 
questions:

(1) Why not just mine the description out of the Description field
    of the SRPM?

(2) Don't RPMs have their own internal checksum?

If the answer to (2) is no, seems to me the thing to do would be to 
enhance RPM to do its own MD5 checksumming and require submitters to
be using a version new enough to have that feature.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>