Heads-up: brand new RPM version about to hit rawhide

[Doug Ledford]

On Sat, 2008-07-12 at 21:00 +0200, Nicolas Mailhot wrote:
> Le samedi 12 juillet 2008 à 14:30 -0400, Doug Ledford a écrit :
> 
> > Even if I thought Panu would take the header changes and any other
> > possible things I might do to RPM, if the other people who control these
> > other items of Fedora infrastructure are dead set against this type of
> > work, then it's a waste of my time to futz around with it unless I'm
> > willing to fork my own distro.  The responses I've gotten so far have
> > not made me inclined to think the powers that be will even look at
> > things, but I could be wrong.
> 
> As Jesse Keating tried to tell you, the reality is that the owerwhelming
> majority

First, before I respond to the rest of this, keep in mind that the
"overwhelming majority" of packages needs to be quantified.
Furthermore, at least one very significant package (the kernel) does not
massage files at all between SCM tag and tarball.  And to be honest, I
would be very surprised to find many projects that do have any
significant difference between a tagged release in the SCM of their
choice and their tarballs.  So I would like some examples please, which
shouldn't be hard to come up with since it is the "overwhelming
majority" of projects that obviously think when they tag something in
their SCM it doesn't need to match the tarball they make with the same
tag version...

>  of the code we package is not pure VCS dumps, because upstreams
> massage their files manually before doing official releases, so being
> able to base a package on a precise tar.gz as posted on upstream's
> homepage is a hard requirement.

No, it's a *policy* that we base things on a precise tarball on some
web/ftp server.  It's a policy that is no better or worse than basing a
package on a precise tagged source version in an SCM.  And to be honest,
I couldn't care less if upstream's tarball and their SCM version match
or not.  It's not important that they match, it's important that we pick
one to be canonical, that we make our choice of which is canonical clear
and apparent to everyone, and then we use that source consistently
within that package.  That's all that matters.  Claiming that a precise
tar.gz is a hard requirement is patently fallacious.  It's currently a
hard requirement *solely* because we haven't integrated cloned SCM repo
support in Fedora yet, and since we are talking about implementing
exactly that support, it negates this "hard" requirement.

> As long as your system can take this into account I don't think anyone
> would mind having a more modern way to manage the stuff we put around
> this upstream archive.

Sorry, but if I do the work, then I'm writing it to eliminate the
tarball.  You don't have to switch your package to this new method if
you don't wish, but I'll be switching my packages over and they will
never touch a tarball again.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

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