From byte at aeon.com.my Wed May 11 04:01:36 2005
From: byte at aeon.com.my (Colin Charles)
Date: Wed, 11 May 2005 14:01:36 +1000
Subject: [Fedora-packaging] Update guidelines with packages from CVS
Message-ID: <1115784096.4052.223.camel@arena.soho.bytebot.net>
So, I think its time spot updated:
http://fedoraproject.org/wiki/PackagingGuidelines
Just to mention to packagers how cvs/svn/arch checkouts are to be
packaged. Some software never gets released (think say, Planet), and
it'd be a good idea that folk had the proper way to package things
So 0.0.`date` (of course make sure that date is not an escaped one, I'm
just being lazy here to write todays date) and a little note about the
fact that it came outta cvs/etc... would be good
Thanks
--
Colin Charles, http://www.bytebot.net/
From tcallawa at redhat.com Sun May 15 17:02:00 2005
From: tcallawa at redhat.com (Tom 'spot' Callaway)
Date: Sun, 15 May 2005 12:02:00 -0500
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <1115784096.4052.223.camel@arena.soho.bytebot.net>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
Message-ID: <1116176520.5350.49.camel@localhost.localdomain>
On Wed, 2005-05-11 at 14:01 +1000, Colin Charles wrote:
> So, I think its time spot updated:
> http://fedoraproject.org/wiki/PackagingGuidelines
>
> Just to mention to packagers how cvs/svn/arch checkouts are to be
> packaged. Some software never gets released (think say, Planet), and
> it'd be a good idea that folk had the proper way to package things
>
> So 0.0.`date` (of course make sure that date is not an escaped one, I'm
> just being lazy here to write todays date) and a little note about the
> fact that it came outta cvs/etc... would be good
Is there any precedent for this in FC (or in old fedora.us, or anywhere
else)?
Basically, do I need to invent this standard from the ground up, or is
there some existing standard that just needs to be documented?
Feedback is welcomed.
~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!
From bugs.michael at gmx.net Sun May 15 17:12:30 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Sun, 15 May 2005 19:12:30 +0200
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <1116176520.5350.49.camel@localhost.localdomain>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
Message-ID: <20050515191230.37f684ae.bugs.michael@gmx.net>
On Sun, 15 May 2005 12:02:00 -0500, Tom 'spot' Callaway wrote:
> On Wed, 2005-05-11 at 14:01 +1000, Colin Charles wrote:
> > So, I think its time spot updated:
> > http://fedoraproject.org/wiki/PackagingGuidelines
> >
> > Just to mention to packagers how cvs/svn/arch checkouts are to be
> > packaged. Some software never gets released (think say, Planet), and
> > it'd be a good idea that folk had the proper way to package things
> >
> > So 0.0.`date` (of course make sure that date is not an escaped one, I'm
> > just being lazy here to write todays date) and a little note about the
> > fact that it came outta cvs/etc... would be good
>
> Is there any precedent for this in FC (or in old fedora.us, or anywhere
> else)?
>
> Basically, do I need to invent this standard from the ground up, or is
> there some existing standard that just needs to be documented?
>
> Feedback is welcomed.
Fedora.us' vepoch concept, which means to move the most significant part
of %version-%release into the release tag and place any less significant
portions to the right of it, e.g.:
fontforge-0.0-2.20050310.fc4.i386.rpm
^
http_ping-0.0-3.20020403.i386.rpm
^
libuninameslist-0.0-3.040707.i386.rpm
^
openal-0.0-0.3.20040726.i386.rpm
^^^
Don't use 0.0.`date` as it would be larger than 0.0.1, which could be the
first release of a program. Instead, move the snapshot date into the
release tag.
From tcallawa at redhat.com Sun May 15 17:24:43 2005
From: tcallawa at redhat.com (Tom 'spot' Callaway)
Date: Sun, 15 May 2005 12:24:43 -0500
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <20050515191230.37f684ae.bugs.michael@gmx.net>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
Message-ID: <1116177883.5350.57.camel@localhost.localdomain>
On Sun, 2005-05-15 at 19:12 +0200, Michael Schwendt wrote:
> Fedora.us' vepoch concept, which means to move the most significant part
> of %version-%release into the release tag and place any less significant
> portions to the right of it, e.g.:
>
> fontforge-0.0-2.20050310.fc4.i386.rpm
> ^
> http_ping-0.0-3.20020403.i386.rpm
> ^
> libuninameslist-0.0-3.040707.i386.rpm
> ^
> openal-0.0-0.3.20040726.i386.rpm
> ^^^
>
> Don't use 0.0.`date` as it would be larger than 0.0.1, which could be the
> first release of a program. Instead, move the snapshot date into the
> release tag.
So, under current guidelines, that would basically mean:
# cvsdate should be in the format YYYYMMDD
%define cvsdate 20050515
# 0.0 is used for applications that do not have a proper version number.
Version: 0.0
# Increment first digit of release if making a change without new source
# checkout, if new source checkout, reset to 1.
Release: 1.%cvsdate%{?dist}
Does that seem reasonable?
~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!
From bugs.michael at gmx.net Sun May 15 20:52:23 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Sun, 15 May 2005 22:52:23 +0200
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <1116177883.5350.57.camel@localhost.localdomain>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
Message-ID: <20050515225223.613cf5ff.bugs.michael@gmx.net>
On Sun, 15 May 2005 12:24:43 -0500, Tom 'spot' Callaway wrote:
> On Sun, 2005-05-15 at 19:12 +0200, Michael Schwendt wrote:
>
> > Fedora.us' vepoch concept, which means to move the most significant part
> > of %version-%release into the release tag and place any less significant
> > portions to the right of it, e.g.:
> >
> > fontforge-0.0-2.20050310.fc4.i386.rpm
> > ^
> > http_ping-0.0-3.20020403.i386.rpm
> > ^
> > libuninameslist-0.0-3.040707.i386.rpm
> > ^
> > openal-0.0-0.3.20040726.i386.rpm
> > ^^^
> >
> > Don't use 0.0.`date` as it would be larger than 0.0.1, which could be the
> > first release of a program. Instead, move the snapshot date into the
> > release tag.
>
> So, under current guidelines, that would basically mean:
>
> # cvsdate should be in the format YYYYMMDD
> %define cvsdate 20050515
> # 0.0 is used for applications that do not have a proper version number.
> Version: 0.0
> # Increment first digit of release if making a change without new source
> # checkout, if new source checkout, reset to 1.
> Release: 1.%cvsdate%{?dist}
>
> Does that seem reasonable?
Yes, IMO.
For snapshots of software with a previous release, i.e. with a real %
version, the string "cvs" or "svn" after cvsdate in the release field
would make it more clear that it's a post-release snapshot.
From mattdm at mattdm.org Sun May 15 20:56:11 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 15 May 2005 16:56:11 -0400
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <20050515225223.613cf5ff.bugs.michael@gmx.net>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
Message-ID: <20050515205611.GA2591@jadzia.bu.edu>
On Sun, May 15, 2005 at 10:52:23PM +0200, Michael Schwendt wrote:
> > So, under current guidelines, that would basically mean:
> > # cvsdate should be in the format YYYYMMDD
> > %define cvsdate 20050515
> > # 0.0 is used for applications that do not have a proper version number.
> > Version: 0.0
> > # Increment first digit of release if making a change without new source
> > # checkout, if new source checkout, reset to 1.
> > Release: 1.%cvsdate%{?dist}
> > Does that seem reasonable?
> Yes, IMO.
> For snapshots of software with a previous release, i.e. with a real %
> version, the string "cvs" or "svn" after cvsdate in the release field
> would make it more clear that it's a post-release snapshot.
So:
Release: 1.cvs%{cvsdate}%{?dist}
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
Current office temperature: 73 degrees Fahrenheit.
From tcallawa at redhat.com Sun May 15 22:43:46 2005
From: tcallawa at redhat.com (Tom 'spot' Callaway)
Date: Sun, 15 May 2005 17:43:46 -0500
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <20050515225223.613cf5ff.bugs.michael@gmx.net>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
Message-ID: <1116197026.5350.91.camel@localhost.localdomain>
On Sun, 2005-05-15 at 22:52 +0200, Michael Schwendt wrote:
> > So, under current guidelines, that would basically mean:
> >
> > # cvsdate should be in the format YYYYMMDD
> > %define cvsdate 20050515
> > # 0.0 is used for applications that do not have a proper version number.
> > Version: 0.0
> > # Increment first digit of release if making a change without new source
> > # checkout, if new source checkout, reset to 1.
> > Release: 1.%cvsdate%{?dist}
> >
> > Does that seem reasonable?
>
> Yes, IMO.
>
> For snapshots of software with a previous release, i.e. with a real %
> version, the string "cvs" or "svn" after cvsdate in the release field
> would make it more clear that it's a post-release snapshot.
This is ok, its a logical extension of the "Non-Numeric Version in
Release" in PackageNamingGuidelines. We should come up with standardized
naming for the common version control systems ("cvs", "svn", "bk",
"git", "arch"). If there are no objections, I'll just use the ones in
the previous line. :)
Of course, this raises a few more issues:
Strictly speaking, as this falls under the "Non-Numeric Version in
Release" case, we should have a preceeding 0.
This changes the example case to:
# cvsdate should be in the format YYYYMMDD
%define cvsdate 20050515
# 0.0 is used for applications that do not have a proper version number.
Version: 0.0
# When the checkout is for a "pre-release", prepend with "0."
# The build digit starts at 1, and increments if making a change
# without new source checkout. If there is a new source checkout, reset
# the second digit to 1.
Release: 0.1.%{cvsdate}cvs%{?dist}
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-1.20050514cvs.noarch.rpm (post-release cvs co)
The problem is that 1.20050514cvs < 2, when it should be considered as
greater.
One possible workaround would be to increment the version number.
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.1-1.20050514cvs.noarch.rpm (post-release cvs co)
foo-1.1-2.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
The problem with this solution is that we're relying on the psychic
abilities of the packager to guess the next release version. For some
packages, this may be possible (they bump version number early in the
source), but its a risky bet, since they could just as easily call the
next release 1.01. Then we have to use Epoch, and the end user remains
confused as to how foo-1.1 < foo-1.01.
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.
~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!
From bugs.michael at gmx.net Mon May 16 00:32:22 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Mon, 16 May 2005 02:32:22 +0200
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <1116197026.5350.91.camel@localhost.localdomain>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
<1116197026.5350.91.camel@localhost.localdomain>
Message-ID: <20050516023222.790bf4de.bugs.michael@gmx.net>
On Sun, 15 May 2005 17:43:46 -0500, Tom 'spot' Callaway wrote:
> Of course, this raises a few more issues:
>
> Strictly speaking, as this falls under the "Non-Numeric Version in
> Release" case, we should have a preceeding 0.
>
> This changes the example case to:
>
> # cvsdate should be in the format YYYYMMDD
> %define cvsdate 20050515
> # 0.0 is used for applications that do not have a proper version number.
> Version: 0.0
> # When the checkout is for a "pre-release", prepend with "0."
> # The build digit starts at 1, and increments if making a change
> # without new source checkout. If there is a new source checkout, reset
> # the second digit to 1.
> Release: 0.1.%{cvsdate}cvs%{?dist}
Why? 0.0 is not the expected version of the final/stable release. So a
"0." prefix in %release is not needed and doesn't make sense either.
Only if %version is at final version already and if you want to keep
non-numerical parts, like "rc" or "alpha", outside %version, you move them
into %release and use a prefix, so the final release can start at 1.
> 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-1.20050514cvs.noarch.rpm (post-release cvs co)
>
> The problem is that 1.20050514cvs < 2, when it should be considered as
> greater.
This is a problem not limited to comparing stable releases with
snapshots. It's a pretty ordinary case. Assume you have:
foo-1.0-1.fc3.i386.rpm (stable release)
foo-1.0-2.20050514cvs.fc4.i386.rpm (post-release snapshot)
and then:
foo-1.0-2.fc3.i386.rpm (first erratum)
* foo-1.0-3.fc3.i386.rpm (second erratum)
The one with '*' is newer than the .fc4 snapshot. Compare that with a .fc4
package, which has a cvs co diff applied as patch and is not marked as a
snapshot in %release:
foo-1.0-1.fc3.i386.rpm (stable release)
foo-1.0-2.fc4.i386.rpm (post-release cvs changes applied as patch)
foo-1.0-2.fc3.i386.rpm (first erratum)
* foo-1.0-3.fc3.i386.rpm (second erratum)
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.
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
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
> One possible workaround would be to increment the version number.
>
> 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.1-1.20050514cvs.noarch.rpm (post-release cvs co)
> foo-1.1-2.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
>
> The problem with this solution is that we're relying on the psychic
> abilities of the packager to guess the next release version.
Exactly. And you could never go back to an older stable release in case
you found major problems in the CVS changes. However:
foo-1.0-3.20050114cvs.fc4.noarch.rpm
foo-1.0-4.fc4.noarch.rpm (revert to last stable release as last resort)
> 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?
fc3:
foo-1.0-1.noarch.rpm (stable release)
foo-1.0-1.2.noarch.rpm (bugfix to stable release)
foo-1.0-1.3.noarch.rpm (security fix to stable release)
fc4:
foo-1.0-2.20041225cvs.noarch.rpm (post-release cvs co)
Later for fc4:
foo-1.0-3.20050301cvs.noarch.rpm (post-release cvs co)
foo-1.0-4.20050514cvs.noarch.rpm (post-release cvs co)
foo-1.0-5.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
Won't solve conflicts magically either, return to "bump most
significant portion of %release with every package release, only reset
to 1 if %version is increased." And if you need to bump %release only
for an older distribution, avoid that the most significant part would
be higher or equal than any package for a newer distribution. Extend
integer release values to floating-point as a last resort,
e.g. 1.fc3 < 1.2.fc3 < 1.3.fc3 < 2.20050514.fc4
Just like the versioning scheme for snapshots, the scheme for pre-releases
is only to avoid unnecessary epoch bumps. Mixed with dist tags, it can get
funny...
From tcallawa at redhat.com Mon May 16 01:40:11 2005
From: tcallawa at redhat.com (Tom 'spot' Callaway)
Date: Sun, 15 May 2005 20:40:11 -0500
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <20050516023222.790bf4de.bugs.michael@gmx.net>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
<1116197026.5350.91.camel@localhost.localdomain>
<20050516023222.790bf4de.bugs.michael@gmx.net>
Message-ID: <1116207611.5350.125.camel@localhost.localdomain>
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!
From bugs.michael at gmx.net Mon May 16 10:03:29 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Mon, 16 May 2005 12:03:29 +0200
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <1116207611.5350.125.camel@localhost.localdomain>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
<1116197026.5350.91.camel@localhost.localdomain>
<20050516023222.790bf4de.bugs.michael@gmx.net>
<1116207611.5350.125.camel@localhost.localdomain>
Message-ID: <20050516120329.59ad6cce.bugs.michael@gmx.net>
On Sun, 15 May 2005 20:40:11 -0500, Tom 'spot' Callaway wrote:
> 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.
No, I didn't mean .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.
No, it isn't. Surely you can avoid the necessity to bump release
for all branches.
> > 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.
No. Read the rest of that example, the part that starts with "and ...".
With your plan I would bump the .fc4 package just for fun? That can't
be true.
> > 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.
Why? My example explains it. If there is no need to update the .fc4
package, why bump it? In this case, it's clearly more convenient to
extend the first number in %release from integer to real number.
> Lets put the CVS case aside for a minute and try to figure out how to do
> this for the "normal" case first.
The CVS case--and the general case of a src.rpm which applies a set of
patches, regardless of whether from CVS--is an important one. It leads to
cases, where you may need to bump release only for one branch, because the
other branches don't need an update. To assume that every bug-fix update
is released for all distribution branches, is a false assumption. There
are competing and conflicting versioning schemes.
From tcallawa at redhat.com Mon May 16 13:28:05 2005
From: tcallawa at redhat.com (Tom 'spot' Callaway)
Date: Mon, 16 May 2005 08:28:05 -0500
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <20050516120329.59ad6cce.bugs.michael@gmx.net>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
<1116197026.5350.91.camel@localhost.localdomain>
<20050516023222.790bf4de.bugs.michael@gmx.net>
<1116207611.5350.125.camel@localhost.localdomain>
<20050516120329.59ad6cce.bugs.michael@gmx.net>
Message-ID: <1116250085.5350.146.camel@localhost.localdomain>
On Mon, 2005-05-16 at 12:03 +0200, Michael Schwendt wrote:
> No, it isn't. Surely you can avoid the necessity to bump release
> for all branches.
Upon rereading your original mail, I still don't see how this is
avoided. Can you help me understand how the following test cases would
work:
(Assume that FC-3 and FC-4 are current, FC-5 in devel. Also keep in mind
the aforementioned Golden Rule, that packages in FC-3 < FC-4)
1. The Normal Case
In the FC-3 repo, you have:
foo-1.0-1.noarch.rpm
In the FC-4 repo, you have:
foo-1.0-2.noarch.rpm
You need to errata the FC-3 repo.
2. The CVS Case (disconnected)
In the FC-3 repo, you start with:
foo-0.0-1.20050315.noarch.com (pre-release cvs checkout)
In FC-4, you need a later checkout:
foo-0.0-1.20050515.noarch.com
The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4
does not.
3. The CVS Case (same source)
In the FC-3 repo, you start with:
foo-0.0-1.20050515.noarch.com
You use the same cvs co for the FC-4 repo:
foo-0.0-1.20050515.noarch.com
Resolve the conflict in naming between branches, and perform an FC-3
only package errata.
(Note that I have avoided dist tag usage on purpose to avoid
"complicating" the issue, but if they're useful in your solutions, feel
free to reintroduce them here)
Thanks in advance,
~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!
From bugs.michael at gmx.net Mon May 16 15:43:53 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Mon, 16 May 2005 17:43:53 +0200
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <1116250085.5350.146.camel@localhost.localdomain>
References: <1115784096.4052.223.camel@arena.soho.bytebot.net>
<1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
<1116197026.5350.91.camel@localhost.localdomain>
<20050516023222.790bf4de.bugs.michael@gmx.net>
<1116207611.5350.125.camel@localhost.localdomain>
<20050516120329.59ad6cce.bugs.michael@gmx.net>
<1116250085.5350.146.camel@localhost.localdomain>
Message-ID: <20050516174353.4c3cb3f5.bugs.michael@gmx.net>
On Mon, 16 May 2005 08:28:05 -0500, Tom 'spot' Callaway wrote:
> On Mon, 2005-05-16 at 12:03 +0200, Michael Schwendt wrote:
>
> > No, it isn't. Surely you can avoid the necessity to bump release
> > for all branches.
>
> Upon rereading your original mail, I still don't see how this is
> avoided. Can you help me understand how the following test cases would
> work:
>
> (Assume that FC-3 and FC-4 are current, FC-5 in devel. Also keep in mind
> the aforementioned Golden Rule, that packages in FC-3 < FC-4)
>
> 1. The Normal Case
>
> In the FC-3 repo, you have:
>
> foo-1.0-1.noarch.rpm
>
> In the FC-4 repo, you have:
>
> foo-1.0-2.noarch.rpm
>
> You need to errata the FC-3 repo.
First of all, more normal would be that the FC-4 package suffers from the
same defects than the FC-3 package, so both branches need an update. In
that case it's a scenario where dist tags make sense.
If however you really mean that no erratum for FC-4 is needed, you
would not bump its release just make your "golden rule" happy, but
instead keep the FC-3 erratum "older than" the latest FC-4 package:
foo-1.0-1.noarch.rpm (FC-3)
=> foo-1.0-1.2.noarch.rpm (erratum for FC-3)
> 2. The CVS Case (disconnected)
>
> In the FC-3 repo, you start with:
>
> foo-0.0-1.20050315.noarch.com (pre-release cvs checkout)
>
> In FC-4, you need a later checkout:
>
> foo-0.0-1.20050515.noarch.com
>
> The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4
> does not.
This is my earlier example. Solution as above:
foo-0.0-1.2.20050315.noarch.com (fixed pre-release cvs checkout)
> 3. The CVS Case (same source)
>
> In the FC-3 repo, you start with:
>
> foo-0.0-1.20050515.noarch.com
>
> You use the same cvs co for the FC-4 repo:
>
> foo-0.0-1.20050515.noarch.com
>
> Resolve the conflict in naming between branches, and perform an FC-3
> only package errata.
Same as 1.
The example is flawed, because it violates your golden rule already
prior to the needed erratum.
> (Note that I have avoided dist tag usage on purpose to avoid
> "complicating" the issue, but if they're useful in your solutions, feel
> free to reintroduce them here)
>
> Thanks in advance,
Dist tags don't help in these cases, since they are the least significant
portion of EVR and don't add any value if you bump the most significant
portion of Release only on an older branch.
[...]
We can continue to collect and examine problematic cases and possible
solutions for them. E.g. ways to avoid Epoch inflation. But I'm inclined to
say that the search for an ultimate versioning scheme would only result in
a document much more complex than fedora.us' old versioning scheme.
From mattdm at mattdm.org Mon May 16 16:32:27 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 16 May 2005 12:32:27 -0400
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <20050516174353.4c3cb3f5.bugs.michael@gmx.net>
References: <1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
<1116197026.5350.91.camel@localhost.localdomain>
<20050516023222.790bf4de.bugs.michael@gmx.net>
<1116207611.5350.125.camel@localhost.localdomain>
<20050516120329.59ad6cce.bugs.michael@gmx.net>
<1116250085.5350.146.camel@localhost.localdomain>
<20050516174353.4c3cb3f5.bugs.michael@gmx.net>
Message-ID: <20050516163227.GA1812@jadzia.bu.edu>
On Mon, May 16, 2005 at 05:43:53PM +0200, Michael Schwendt wrote:
> > In the FC-3 repo, you start with:
> > foo-0.0-1.20050315.noarch.com (pre-release cvs checkout)
> > In FC-4, you need a later checkout:
> > foo-0.0-1.20050515.noarch.com
> > The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4
> > does not.
> This is my earlier example. Solution as above:
> foo-0.0-1.2.20050315.noarch.com (fixed pre-release cvs checkout)
Except, isn't that *older* than foo-0.0-1.20050315? (2 < 20050315)?
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
Current office temperature: 71 degrees Fahrenheit.
From bugs.michael at gmx.net Mon May 16 17:00:25 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Mon, 16 May 2005 19:00:25 +0200
Subject: [Fedora-packaging] Update guidelines with packages from CVS
In-Reply-To: <20050516163227.GA1812@jadzia.bu.edu>
References: <1116176520.5350.49.camel@localhost.localdomain>
<20050515191230.37f684ae.bugs.michael@gmx.net>
<1116177883.5350.57.camel@localhost.localdomain>
<20050515225223.613cf5ff.bugs.michael@gmx.net>
<1116197026.5350.91.camel@localhost.localdomain>
<20050516023222.790bf4de.bugs.michael@gmx.net>
<1116207611.5350.125.camel@localhost.localdomain>
<20050516120329.59ad6cce.bugs.michael@gmx.net>
<1116250085.5350.146.camel@localhost.localdomain>
<20050516174353.4c3cb3f5.bugs.michael@gmx.net>
<20050516163227.GA1812@jadzia.bu.edu>
Message-ID: <20050516190025.292e5da1.bugs.michael@gmx.net>
On Mon, 16 May 2005 12:32:27 -0400, Matthew Miller wrote:
> On Mon, May 16, 2005 at 05:43:53PM +0200, Michael Schwendt wrote:
> > > In the FC-3 repo, you start with:
> > > foo-0.0-1.20050315.noarch.com (pre-release cvs checkout)
> > > In FC-4, you need a later checkout:
> > > foo-0.0-1.20050515.noarch.com
> > > The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4
> > > does not.
> > This is my earlier example. Solution as above:
> > foo-0.0-1.2.20050315.noarch.com (fixed pre-release cvs checkout)
>
> Except, isn't that *older* than foo-0.0-1.20050315? (2 < 20050315)?
Yes, .2 inserted in the wrong place. In the context of above scenario:
FC-3: foo-0.0-1.20050315.noarch.rpm
FC-4: foo-0.0-1.20050515.noarch.rpm
FC-3 => foo-0.0-1.20050315.2.noarch.rpm
The leading 1. is most-significant here to overrule the snapshot date, so
an update to 1.20050315 would be created by appending a least-significant
digit.