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

[Nils Philippsen]

On Mon, 2008-07-14 at 10:53 -0400, Doug Ledford wrote:
> 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.  

Hmm, but "it might be nice" isn't a sufficient reason for me to enforce
unchangeable tags -- "it has built successfully" would be, though. Or
rather, let the successful build trigger the tagging of the built
revision.

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

Heh, but these parts should have been put elsewhere in the first place,
don't you think ;-)? 

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011