[Fedora-packaging] Update guidelines with packages from CVS

[Tom 'spot' Callaway]

On Mon, 2005-05-16 at 02:32 +0200, Michael Schwendt wrote:

>   foo-1.0-1.fc3.i386.rpm (stable release)
>   foo-1.0-2.20050514cvs.fc4.i386.rpm (post-release snapshot)

These two packages will never compare, unless you're doing a dist
upgrade. But I'll assume you meant .fc3 for both rpms.

> If the .fc4 cvs snapshot doesn't need an update, you get the same
> problems. Dist tags don't help in that case either. They only help for
> updates applied to multiple distribution versions at once.
> 
> Whenever you bump %release only on an older branch, you increase the
> likelihood that you violate the distribution upgrade path.

Then you have to bump it on both. We have to enforce that n-v-r of the
previous current branch must be less than the current branch, if we want
to be able to do upgrades. This is true with or without disttags.

> This can also happen if you have use an older cvs snapshot for FC3
> and a recent one for FC4,
> 
>   foo-0.0-1.20040903cvs.fc3.i386.rpm
>   foo-0.0-1.20050514cvs.fc4.i386.rpm

Well, no. In this case, the fc4 package is newer according to rpm. No
conflict in each branch, no conflict on dist upgrade. The conflict only
arises when you bump the FC-3 branch release, without bumping the FC-4
branch.

> and if you need to fix a security bug in the old snapshot and you
> can't upgrade to latest cvs co because build requirements are insufficient,
> you run into %release conflicts again:
> 
> * foo-0.0-2.20040903cvs.fc3.i386.rpm
>   foo-0.0-1.20050514cvs.fc4.i386.rpm

Again, this problem is avoided if both branches are incremented
together.

The golden rule is that for supported release branches (not in devel),
the packages in the most recent branch must be greater in n-v-r than the
branch before it (and the branch before that, in the 3 supported release
case). I know we're trying to keep the buildsystem dumb, but we might
have to check for this at buildtime.

This is a problem that the cvs dates are overcomplicating.

If you have this package in FC-3:

foo-1.0-3.fc3.noarch.rpm

Then, your FC-4 package should have a higher n-v-r. If the v is the
same, then the r has to be higher. With dist tags, you can have:

foo-1.0-3.fc4.noarch.rpm

Which is higher, and requires only that the release number be consistent
between the branches. When you errata either, you bump both release
numbers. Realistically speaking, the probability of both branches having
the same n-v but not needing the same fix is slim, so this isn't a
terrible requirement in my mind.

Without dist tags, in the FC-3 branch you'd have:

foo-1.0-3.noarch.rpm 

And you'd need this in the FC-4 branch:

foo-1.0-4.noarch.rpm

Which causes problems if you have to errata the FC-3 branch, causing you
to leapfrog to 5 (and then 6 in the FC-4 branch).

Either methodology will require rebuilds of both branches. Using dist
tags keeps the numbers lower.

> > Another workaround would be to use the value of the highest %{release}
> > number from the stable release as the new "build digit".
> > 
> > With this, we'd have:
> > foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co)
> > foo-1.0-1.noarch.rpm (stable release)
> > foo-1.0-2.noarch.rpm (bugfix to stable release)
> > foo-1.0-2.20050514cvs.noarch.rpm (post-release cvs co)
> > foo-1.0-3.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
> > 
> > I'm inclined to document the latter option as the standard, but I'm open
> > to advice/alternatives here.
> 
> That is no silver bullet either. A second bugfix to the stable release,
> and you would get into trouble again. Why not just increase release in the
> context of all current packages?

I was presenting this case in a single branch. This only works if the
golden rule above is followed.

The trick is making a packaging standard which makes it easy to follow
the golden rule, and difficult not to.

Lets put the CVS case aside for a minute and try to figure out how to do
this for the "normal" case first.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!