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

[Doug Ledford]

On Mon, 2008-07-14 at 16:36 +0200, Nils Philippsen wrote:
> On Mon, 2008-07-14 at 10:20 -0400, Doug Ledford wrote:
> > On Mon, 2008-07-14 at 09:21 +0200, Nils Philippsen wrote:
> > > On Sat, 2008-07-12 at 20:12 -0400, Doug Ledford wrote:
> > > > On Sat, 2008-07-12 at 16:09 -0400, Jesse Keating wrote:
> > > [...]
> > > > > The problem really lies with whether or not this would satisfy, as a
> > > > > written offer, the requirements under which we distribute or ask our
> > > > > ambassadors to distribute our binaries.
> > > > 
> > > > OK, well regardless, if this meets the requirements, then certainly an
> > > > immutably tagged exploded SCM would too (for far less space requirements
> > > 
> > > Leaving aside discussing the merits of it, you don't need to use
> > > immutable tags (pkg-1_0-1_fcX) as you can just record the exact revision
> > > from which you built the package (which should already be immutable).
> > 
> > You are correct on that point, but the immutable tag is generally more
> > readable as part of the output of rpm -i <binary package>.
> 
> I don't understand why that thing should be (human-)readable, it's just
> a pointer to the exact state of things which was used to build a binary
> package.

It doesn't have to be, but it might be nice.  I would find it far easier
to parse the tag in my head than the sha.  That's one complaint I have
with git, I rather wish it would hide the shas instead of putting them
front and center.  But, that's just personal preference.

> Correlating this to a human-readable version/release needs to be done of
> course so that these make sense. I think it should be done in a way
> where the resulting SRPMs still contain what amounts to the upstream
> tarball plus patch(es) so that you can easily pass around self-contained
> source packages where it is clear what is upstream and what
> Fedora/RHEL/... added. 
> 
> Note that this doesn't necessarily mean that a developer can't work in
> an exploded tree -- I think the patches could be generated from an
> exploded tree. To ensure that this really works (and the packages are
> self-contained), the build system would probably have to use these
> source packages for building and not work directly from the exploded
> tree.

We do this internally now for the RHEL4 and RHEL5 kernels.  The kernel
maintainer has a git repo, we work from that repo, we send patches to
the maintainer internally, they commit to the repo, then come build
time, they spit out a tarball and a set of patches to import into CVS
and then the build happens from CVS.  It's cumbersome, and it introduces
a few problems in that if you make a patch that touches file that are
part of the git repo itself, but not part of what you want exported to
the CVS checkins (such as patches to the scripts that generate a tarball
and patches from the git repo), then those have to be filtered out
before you check things into CVS etc.

-- 
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/20080714/ace1edb2/attachment.sig>