rawhide report: 20070108 changes

Toshio Kuratomi a.badger at gmail.com
Thu Jan 11 01:35:59 UTC 2007


On Tue, 2007-01-09 at 11:29 -0500, Jesse Keating wrote:
> On Tuesday 09 January 2007 11:23, Nicolas Mailhot wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.20-rc4.tar.bz2
> >
> > (Just to disprove this argument, you could push it a tad further and
> > suggest to distinguish between .tar.bz2, tar.gz & zip source archives in
> > rpm versions)
> 
> While there is a tarball there, you'll see we're not using it in our kernel 
> package.  Using the stack of patches has other bonuses, being able to opt out 
> of some of them, possibly easier to integrate our patches into the mix, etc..
> 
This is sound reasoning.  I haven't seen anyone advocate for changing
Dave's workflow in this regard, yet.

> So our package really isn't the 2.6.20-rc4 release, it's 2.6.19 plus all the 
> patches that is leading up to 2.6.20.

I think that's a bit of a stretch.  If I started with gtk2-2.10.4.tar.gz
and applied a patch to make it kernel-2.6.20-rc4, would I have a kernel
package or a gtk2 package?

Axel has pointed out one benefit of changing from 2.6.(x-1) to 2.6.x
internally when we rebase to an rc.  What are the problems with this?
If the internal version was to change as Axel suggests, then it would
definitely make sense for the rpm version to change as well -- and at
that point it might as well conform to the Fedora Guidelines.

Although I agree that the kernel is special, I'm not yet seeing why
there'd be a problem with the kernel following the naming guidelines.
If someone can point out where the naming guidelines fail to provide for
a properly upgrading EVR, it would help clarify why an exception should
be made.

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


More information about the fedora-devel-list mailing list