rawhide report: 20070108 changes

[Dave Jones]

On Tue, Jan 09, 2007 at 06:55:12PM +0100, Thorsten Leemhuis wrote:
 > Dave Jones schrieb:
 > > On Tue, Jan 09, 2007 at 08:15:10AM -0500, Jesse Keating wrote:
 > >  > On Tuesday 09 January 2007 02:22, Thorsten Leemhuis wrote:
 > >  > > If I would review the kernel for the extras merge I'd say "fix this".
 > >  > > But I suspect davej won't like to call the kernels 2.6.20 (e.g.
 > >  > > 2.6.20-1.2906.rc4.fc7 for example) before they are actually 2.6.20.
 > >  > > This will be one of the problem areas we'll probably have to deal with
 > >  > > when it comes to reviewing Core packages for the Extras merge.
 > >  > Personally, I'm all for giving the kernel a pass on this and some of the 
 > >  > other... interesting things in the spec.  That is, unless the reviewer not 
 > >  > only complains about something in the spec, but also produces a viable rework 
 > >  > of what the spec is trying to accomplish.  The kernel is one of our speshul 
 > >  > packages that really does need some special consideration.
 > > Really.  And if you want to do something useful with the kernel package,
 > > there's no shortage of real bugs that need fixing.
 > 
 > There are guidelines for packaging. They contain a standard for naming
 > pre-release packages. The kernel package clearly is violating it as the
 > version of the kernel is in fact 2.6.20-rc4, but the %version is 2.6.19.
 > Can we agree so far?

I don't consider rc's as released versions. The package version number
should state the latest released version that package is based on.
If we were to go down this route, we'd have to contend with the
other upstream naming conventions too.
look at the combinations we have :- 2.6.19, 2.6.19-git1, 2.6.19-rc1, 2.6.19.1,
2.6.19-rc1-git1, 2.6.19.1-rc1

If rpmvercmp gets all of those transitions correct, I'll be surprised.

 > Okay, next step: Are you asking us to ignore that during the review for
 > the merge? BTW, sure, we can't fix each and every detail of a complex
 > package like the kernel-one. But the wrong pre-relase-version one is
 > fixed easily and I think that actually why we do the big review for the
 > merge.

We've got much bigger fish to fry, and this afaics can only introduce problems.

		Dave

-- 
http://www.codemonkey.org.uk