http://www.fedora.us/wiki/PackageNamingGuidelines The following is based upon current fedora.us package naming guidelines, quickly edited and dramatically simplified because fedora.redhat.com no longer needs many of fedora.us special considerations.
The below proposal is ALMOST EXACTLY THE SAME as fedora.us current scheme except with the leading "0.fdr." removed from all %{release} tags. I would assert that fedora.us package naming scheme has demonstrated to be a great success, thus it should continued in fedora.redhat.com. The below scheme is also in-line with the common practices used by most of Red Hat's existing packages.
This proposal is missing considerations for 3rd party repositories. Theoretically 3rd party repositories should no longer have a reason to publish the same %{name} of any packages that exist in FC or FE because changes should be incorporated upstream. There are however some cases like kde-redhat where this is not possible, so we really need to discuss possible solutions to this. Earlier we had discussed the possibility of simply adding a %{reptag} to the far right of %{release}.
Fedora Package Naming Guidelines Warren's Proposal for fedora.redhat.com Revision 1 ================================ i. Introduction Goals for package naming guidelines ii. Terminology A. Package Name B. Version C. Release Tag 1. Release Prefix 2. Vepoch 3. Non-Numeric Version to Release 4. Dist tag 5. Special: Kernel modules 6. Special: Plugin, theme etc packages 7. Special: Minor Number
i. Introduction =============== Goals for the Fedora Package Naming Guidelines * Easily understandable package naming policy * Indication of the original source version (end-user convenience) * Allow for a smooth upgrade path between multiple levels of testing branches and future distribution upgrades. This means E-V-R must never be exactly identical between distribution versions. * Minimize the chance of package conflicts for future Fedora distribution upgrades.
ii. Terminology ============== name This is the "Name" field of RPM .spec files.
version This is the "Version" field of RPM .spec files.
release tag This is the "Release" field of RPM .spec files.
dist tag This is a distribution tag indicating which RHL/FC distribution this package is intended for. This only occurs in cases where packages from different distributions are built from the same SRPM and patchlevel.
vepoch This is our term for "version specific epoch", used in all packages as a simple means of ensuring upgrades by simple incrementing the leading number within the release tag. vepoch is otherwise known as "release number" or "patchlevel". Read C-2 for more information.
E-V-R Abbreviation for epoch, version, and release. This is often referred to when talking about potential package upgrading problems.
A. Package Name =============== Package name should preferably match the upstream tarball or project name from which this software came. In some cases this naming choice is more complicated. If this package has been packaged by other distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS, etc.) in the past, then we should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision.
Ultimately it is up to QA to decide upon the proper %{name} before publication.
B. Version ========== If the version is only numbers, then these numbers can be put into the "version" field of the RPM .spec unchanged. If the version contains non-numeric characters, this creates several problems for RPM version comparison and a broken upgrade path.
Example: foobar-1.2.3beta1.tar.gz foobar-1.2.3.tar.gz
While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM version comparison thinks the former is newer.
Example: foobar-1.0a foobar-1.0b
The "1.0b" version is higher than "1.0a", but all versions of RPM prior to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever package is first in the comparison "wins", thus this becomes a two way upgrade problem. This a < b comparison works properly only in RH9 and higher.
For simplicity, Fedora treats both pre-release and post-release non-numeric version cases the same, making the version purely numeric and moving the alphabetic part to the release tag. Take the numeric portion of the source version and make that the package version tag.
Read C-3 for more details.
C. Release Tag ============== The release tag of Fedora packages more complicated, so this is split into several parts.
C-1. Release Prefix ------------------- No longer needed in fedora.redhat.com.
C-2. Vepoch ----------- The leftmost leading number within the release tag is the "version specific epoch" or vepoch in Fedora. This number is incremented with every package update. The vepoch is otherwise known as the "release number" or "patchlevel".
The key difference between the concept of "vepoch" and "patch level" is that everything to the right of the vepoch is PURELY INFORMATIONAL. The only time where it matters is to guarantee a different %{release} tag between two distribution versions.
The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy as canonical. Package updates in any repository should always check all other official repositories to be sure that the vepoch is always incremented and never matching an existing package.
With most normal packages, vepoch is a single number starting at "1". Under the (C-3) non-numeric version case it is two numbers starting at "0.1" with the second number being the number to increment.
Normal Package Example: foobar-1.2.3-1.src.rpm compiles to foobar-1.2.3-1.i386.rpm
If this package is patched: foobar-1.2.3-2.i386.rpm foobar-1.2.3-3.i386.rpm
C-3. Non-Numeric Version to Release ----------------------------------- As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric versioned packages can be problematic so they must be treated with care. These are cases where the upstream version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before or after the number. Read section B to understand why we cannot simply put these letters into the version tag.
Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} Release Tag for Non-Numeric Post-Release Packages: %{X}.%{alphatag} Where %{X} is the vepoch increment, and %{alphatag} is the string that came from the version.
Example (pre-release): mozilla-1.4a.tar.gz from usptream is lower than mozilla-1.4.tar.gz the later "final" version thus mozilla-1.4-0.1.a Fedora package name
Example (pre-release): alsa-lib-0.9.2beta1.tar.gz becomes alsa-lib-0.9.2-0.1.beta1
Example (post-release): gkrellm-2.1.7.tar.gz gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7 gkrellm-2.1.7-1.a
Upgrade Path Example (mozilla): mozilla-1.4-0.1.a Patched mozilla-1.4-0.2.a Patched again mozilla-1.4-0.3.a Move to 1.4b mozilla-1.4-0.4.b Patched mozilla-1.4-0.5.b Move to 1.4 "final" version Notice that this becomes a normal C-2 case mozilla-1.4-1 Patched mozilla-1.4-2
Upgrade Path Example (alsa-lib): alsa-lib-0.9.2-0.1.beta1 Patched alsa-lib-0.9.2-0.2.beta1 Move to beta2 alsa-lib-0.9.2-0.3.beta2 Move to beta3 and simultaneously patch alsa-lib-0.9.2-0.4.beta3 Patched again alsa-lib-0.9.2-0.5.beta3 Move to rc1 alsa-lib-0.9.2-0.6.rc1 Move to rc2 alsa-lib-0.9.2-0.7.rc2 Move to "final" alsa-lib-0.9.2-1 Patched alsa-lib-0.9.2-2
C-4. Dist tag ------------- In cases where the same SRPM and patchlevel is used between two or more distributions supported by Fedora, a dist tag is appended to the end of the release tag defined in C-2 and C-3. The dist tags with the following examples appear to be only cosmetic, however the a different E-V-R is needed between distributions to ensure dist upgrading works fully in all corner cases.
Dist Tag for Normal Packages: %{X}.%{disttag} Where %{X} is the vepoch and %{disttag} is a distribution tag from this table:
0.7.3 Red Hat Linux 7.3 0.8 Red Hat Linux 8 0.9 Red Hat Linux 9 1 Fedora Core 1 1.93 Fedora Core 1.93 beta 1.94 Fedora Core 1.94 beta 2 Fedora Core 2 beta
Example: foobar-1.2.3-1_0.7.3.i386.rpm foobar-1.2.3-1_0.8.i386.rpm foobar-1.2.3-1_0.9.i386.rpm foobar-1.2.3-1_1.94.i386.rpm foobar-1.2.3-1_2.i386.rpm
Upgrade Path Example (FC1 only shown): foobar-1.2.3-1_1.i386.rpm foobar-1.2.3-2_1.i386.rpm foobar-1.2.3-3_1.i386.rpm
Dist Tag for Pre-Release Packages: %{X}.%{alphatag}.%{disttag} Where %{X} is the vepoch, %{alphatag} is the pre-release tag described in C-3, %{disttag} is a distribution tag described above.
Example: alsa-lib-0.9.2-0.1.beta1_0.8.i386.rpm alsa-lib for RH 8.0 alsa-lib-0.9.2-0.1.beta1_1.i386.rpm alsa-lib for FC1
Upgrade Path Example (RH 7.3 only shown): alsa-lib-0.9.2-0.1.beta1_0.7.3 alsa-lib-0.9.2-0.2.beta1_0.7.3 alsa-lib-0.9.2-0.3.beta2_0.7.3 alsa-lib-0.9.2-0.4.beta3_0.7.3 alsa-lib-0.9.2-0.5.beta3_0.7.3 alsa-lib-0.9.2-0.6.rc1_0.7.3 alsa-lib-0.9.2-0.7.rc2_0.7.3 alsa-lib-0.9.2-1_0.7.3 alsa-lib-0.9.2-2_0.7.3
C-5. Special Case: Kernel modules --------------------------------- This section needs its own discussion due to changed provides within FC1's kernel, and the fact that older distributions are different.
C-6. Plugin, theme etc packages ------------------------------- Packages that are plugins, themes or the like, ie. enhance other packages must be named <package-to-enhance>-<enhancement>. If the resulting name differs significantly from upstream naming, a Provides: <upstream-name> = %{epoch}:%{version}-%{release} must be added. For example:
Upstream package name: modplug-xmms Fedora package name: xmms-modplug Provides: modplug-xmms = %{epoch}:%{version}-%{release}
C-7. Minor Number ----------------------- Probably no longer needed at fedora.redhat.com.
Quoting Warren Togami warren@togami.com: <huge snip> Looks good to me. The only thing I don't really like at first sight is separating disttag with underscore rather than something else but then that's probably just a matter of getting used to :) Oh and it's anyway cleaner looking than all the .rh9.0.93.foo type of numberings.
C-5. Special Case: Kernel modules
This section needs its own discussion due to changed provides within FC1's kernel, and the fact that older distributions are different.
Hmm, what's changed? Doesn't look that different to me: Current rawhide kernel: [pmatilai@linox03 RPMS]$ rpm -qp --provides kernel-smp-2.4.22-1.2115.nptl.i686.rpm kernel = 2.4.22 kernel-drm = 4.1.0 kernel-drm = 4.2.0 kernel-drm = 4.3.0 kernel-smp = 2.4.22-1.2115.nptl
Latest RHL9 errata kernel: [pmatilai@linox03 i686]$ rpm -qp --provides kernel-smp-2.4.20-20.9.i686.rpm kernel = 2.4.20 kernel-drm = 4.1.0 kernel-drm = 4.2.0 kernel-drm = 4.2.99.3 kernel-drm = 4.3.0 module-info kernel-smp = 2.4.20-20.9
The only change is the dropped module-info provides but that wasn't used by anything AFAIK, certainly not by the fedora.us kernel-module packages anyway.
That's not to say this topic doesn't deserve a separate discussion of course :)
On Thu, 30 Oct 2003, Warren Togami wrote:
http://www.fedora.us/wiki/PackageNamingGuidelines The following is based upon current fedora.us package naming guidelines, quickly edited and dramatically simplified because fedora.redhat.com no longer needs many of fedora.us special considerations.
Some feedback below...
vepoch This is our term for "version specific epoch", used in all packages as a simple means of ensuring upgrades by simple incrementing the leading number within the release tag. vepoch is otherwise known as "release number" or "patchlevel". Read C-2 for more information.
The "Epoch" tag is already quite confusing to many/most beginner and intermediate packagers, perhaps even some advanced packagers. It's often used when not needed, and with a small amount of forethought when packaging things can be completely avoided in many if not all cases where Epoch ends up being used nowadays by someone.
I think your "vepoch" tag potentially adds confusion between what Epoch is and what vepoch is. I unfortunately don't have a better name to offer other than perhaps "versionserial" to indicate a monotonically increasing serial number tied to a version.
Just a personal opinion that this might confuse people, and if a better name can be chosen that is short enough and clear, it might be better.
A. Package Name
Package name should preferably match the upstream tarball or project name from which this software came. In some cases this naming choice is more complicated. If this package has been packaged by other distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS, etc.) in the past, then we should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision.
Ultimately it is up to QA to decide upon the proper %{name} before publication.
Just to contrast, at Red Hat, package naming is usually determined by the developer who creates a new package from scratch, or who Red Hattifies an existing src.rpm from the wild. I do realize though that when you refer to QA above, you don't mean Red Hat QA, but rather fedora.us QA in sort of a quality control and semi-standardization sense. Sounds like a good idea to me. Also a good idea for people to provide feedback as early on as possible about developer chosen *crappy* package names. I've seen MySQL in rpm format out there named "mysql", "Mysql", "MySQL", and MySql". ICK!
B. Version
If the version is only numbers, then these numbers can be put into the "version" field of the RPM .spec unchanged. If the version contains non-numeric characters, this creates several problems for RPM version comparison and a broken upgrade path.
Example: foobar-1.2.3beta1.tar.gz foobar-1.2.3.tar.gz
While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM version comparison thinks the former is newer.
Example: foobar-1.0a foobar-1.0b
The "1.0b" version is higher than "1.0a", but all versions of RPM prior to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever package is first in the comparison "wins", thus this becomes a two way upgrade problem. This a < b comparison works properly only in RH9 and higher.
For simplicity, Fedora treats both pre-release and post-release non-numeric version cases the same, making the version purely numeric and moving the alphabetic part to the release tag. Take the numeric portion of the source version and make that the package version tag.
Read C-3 for more details.
I strongly agree with this approach. Probably because I stole it from bero, and I think you picked it up from me or from bero also. ;o) It works very well IMHO. It's also very useful with CVS based releases where you can embed the CVS date into the release field instead of the version field, thus avoiding having to use Epoch later on to override the large integer release number from a CVS date.
Example:
This: XFree86-4.3.99.15-0.20031030
is better IMHO, than this: XFree86-20031030-1
The latter one, would require an ugly Epoch bump to upgrade to XFree86 4.4.0 for example. That can be avoided by using the method you describe. (Which is why my CVS rpm packages tend to have insanely long version-release tags <grin>)
C-2. Vepoch
The leftmost leading number within the release tag is the "version specific epoch" or vepoch in Fedora. This number is incremented with every package update. The vepoch is otherwise known as the "release number" or "patchlevel".
The key difference between the concept of "vepoch" and "patch level" is that everything to the right of the vepoch is PURELY INFORMATIONAL. The only time where it matters is to guarantee a different %{release} tag between two distribution versions.
The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy as canonical. Package updates in any repository should always check all other official repositories to be sure that the vepoch is always incremented and never matching an existing package.
With most normal packages, vepoch is a single number starting at "1". Under the (C-3) non-numeric version case it is two numbers starting at "0.1" with the second number being the number to increment.
Normal Package Example: foobar-1.2.3-1.src.rpm compiles to foobar-1.2.3-1.i386.rpm
If this package is patched: foobar-1.2.3-2.i386.rpm foobar-1.2.3-3.i386.rpm
I find the above quite confusing, and I actually understand what your vepoch is there for and why. ;o) Might want to try rewording that perhaps, although I'm not volunteering.... ;o)
C-3. Non-Numeric Version to Release
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric versioned packages can be problematic so they must be treated with care. These are cases where the upstream version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before or after the number. Read section B to understand why we cannot simply put these letters into the version tag.
Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} Release Tag for Non-Numeric Post-Release Packages: %{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that came from the version.
Example (pre-release): mozilla-1.4a.tar.gz from usptream is lower than mozilla-1.4.tar.gz the later "final" version thus mozilla-1.4-0.1.a Fedora package name
Example (pre-release): alsa-lib-0.9.2beta1.tar.gz becomes alsa-lib-0.9.2-0.1.beta1
Example (post-release): gkrellm-2.1.7.tar.gz gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7 gkrellm-2.1.7-1.a
For gkrellm is this necessary? rpm considers 2.1.7a newer than 2.1.7 already unless something has changed. Another package of this nature is UW imap. It is generally released with an integer based version number of the year of it's release, possibly followed by a single letter indicating a revision within that year. ie: imap-2000 imap-2000a imap-2000b
In rpm's normal operation these packages are naturally treated as the older package on the left, with the newer ones proceeding to the right.
My personal preference would be to just let rpm assume that as it should work. I've never gotten bug reports of it not working anyway. Moving things from the version to the release field unnecessarily just complicates packaging when there's no real benefit IMHO. For the pre-release cases above it makes sense as it's being done in order to override rpm's default behaviour, which would be to treat what is a final release as older than a prerelease.
I believe treating both pre-release and post-release in the same manner just for consistency with both types of lettered versioned packages is just cosmetic consistency, but doesn't provide any functional or technical benefit. In other words, sticking with the upstream version in the version field is IMHO best unless there is a technical benefit of doing so, such as avoiding having to later use Epoch to override a prerelease build.
Are there cases where rpm would consider imap-2000a as older than imap-2000?
jbj?
C-4. Dist tag
In cases where the same SRPM and patchlevel is used between two or more distributions supported by Fedora, a dist tag is appended to the end of the release tag defined in C-2 and C-3. The dist tags with the following examples appear to be only cosmetic, however the a different E-V-R is needed between distributions to ensure dist upgrading works fully in all corner cases.
Dist Tag for Normal Packages: %{X}.%{disttag} Where %{X} is the vepoch and %{disttag} is a distribution tag from this table:
0.7.3 Red Hat Linux 7.3 0.8 Red Hat Linux 8 0.9 Red Hat Linux 9 1 Fedora Core 1 1.93 Fedora Core 1.93 beta 1.94 Fedora Core 1.94 beta 2 Fedora Core 2 beta
Example: foobar-1.2.3-1_0.7.3.i386.rpm foobar-1.2.3-1_0.8.i386.rpm foobar-1.2.3-1_0.9.i386.rpm foobar-1.2.3-1_1.94.i386.rpm foobar-1.2.3-1_2.i386.rpm
Upgrade Path Example (FC1 only shown): foobar-1.2.3-1_1.i386.rpm foobar-1.2.3-2_1.i386.rpm foobar-1.2.3-3_1.i386.rpm
Ick. Underscores in version/release are hideous IMHO. I'd use "." instead of "_". Your comment at the top of this section indicates a ".", so perhaps you just made a typo, and sequence of cut and paste errors? ;o)
C-5. Special Case: Kernel modules
This section needs its own discussion due to changed provides within FC1's kernel, and the fact that older distributions are different.
Bah, who needs kernel modules. ;o)
C-6. Plugin, theme etc packages
Packages that are plugins, themes or the like, ie. enhance other packages must be named <package-to-enhance>-<enhancement>. If the resulting name differs significantly from upstream naming, a Provides: <upstream-name> = %{epoch}:%{version}-%{release} must be added. For example:
Upstream package name: modplug-xmms Fedora package name: xmms-modplug Provides: modplug-xmms = %{epoch}:%{version}-%{release}
I agree, this is a sensible diversion from an upstream package IMHO.
C-7. Minor Number
Probably no longer needed at fedora.redhat.com.
Change that to read "MBZ, reserved for future" to cover your bases, and looks good. ;o)
Hope my feedback is useful... if not, feel free to kick me in the pants. ;o)
Take care, TTYL
On Fri, Oct 31, 2003 at 05:53:58AM -0500, Mike A. Harris wrote:
My personal preference would be to just let rpm assume that as it should work. I've never gotten bug reports of it not working anyway. Moving things from the version to the release field unnecessarily just complicates packaging when there's no real benefit IMHO. For the pre-release cases above it makes sense as it's being done in order to override rpm's default behaviour, which would be to treat what is a final release as older than a prerelease.
I believe treating both pre-release and post-release in the same manner just for consistency with both types of lettered versioned packages is just cosmetic consistency, but doesn't provide any functional or technical benefit. In other words, sticking with the upstream version in the version field is IMHO best unless there is a technical benefit of doing so, such as avoiding having to later use Epoch to override a prerelease build.
I agree, and rpm (and deb for this matter) should be redesigned long term to have different semantics of a upstream version used for rpm/deb ordering and one used for the package name. So foo-1.2.3beta17.8 could be packaged as foo-1.2.3beta17.8-1.rh9, but be compared as say 1.2.2.99.17.8.
This could be done at the cost of introducing a new tag like versionsort that defaults to %{version}. When present it would be used for ordering and interpackage dependencies (Requires, Conflicts, Obsoletes etc.).
It would make epochs unnecessary and it would be a local (in time) change of a package (contrasted to epoch's global and eternal presence ...).
This was proposed on the rpm-list ages ago, but died a silent death, maybe it could be resurrected here?
Are there cases where rpm would consider imap-2000a as older than imap-2000?
No, not since rpm >= 4.0.3 (#21392).
Mike A. Harris wrote:
vepoch This is our term for "version specific epoch", used in all packages as a simple means of ensuring upgrades by simple incrementing the leading number within the release tag. vepoch is otherwise known as "release number" or "patchlevel". Read C-2 for more information.
The "Epoch" tag is already quite confusing to many/most beginner and intermediate packagers, perhaps even some advanced packagers. It's often used when not needed, and with a small amount of forethought when packaging things can be completely avoided in many if not all cases where Epoch ends up being used nowadays by someone.
I think your "vepoch" tag potentially adds confusion between what Epoch is and what vepoch is. I unfortunately don't have a better name to offer other than perhaps "versionserial" to indicate a monotonically increasing serial number tied to a version.
Just a personal opinion that this might confuse people, and if a better name can be chosen that is short enough and clear, it might be better.
Hmmm, I am in agreement. While we fedora.us people had no problem with vepoch for many months, I can see where it is confusing. I designed the name to be "Kind of like epoch, vepoch trumps all, but less."
Perhaps "patchlevel" is a better word.
B. Version
If the version is only numbers, then these numbers can be put into the "version" field of the RPM .spec unchanged. If the version contains non-numeric characters, this creates several problems for RPM version comparison and a broken upgrade path.
Example: foobar-1.2.3beta1.tar.gz foobar-1.2.3.tar.gz
While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM version comparison thinks the former is newer.
Example: foobar-1.0a foobar-1.0b
The "1.0b" version is higher than "1.0a", but all versions of RPM prior to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever package is first in the comparison "wins", thus this becomes a two way upgrade problem. This a < b comparison works properly only in RH9 and higher.
For simplicity, Fedora treats both pre-release and post-release non-numeric version cases the same, making the version purely numeric and moving the alphabetic part to the release tag. Take the numeric portion of the source version and make that the package version tag.
Read C-3 for more details.
I strongly agree with this approach. Probably because I stole it from bero, and I think you picked it up from me or from bero also. ;o) It works very well IMHO. It's also very useful with CVS based releases where you can embed the CVS date into the release field instead of the version field, thus avoiding having to use Epoch later on to override the large integer release number from a CVS date.
Yes, when I originally designed this method I was pointing at bero's packages as justification. "See! Look, Red Hat did it!"
Conspiracy theory: Was he canned because of persecution from aberrant packaging? =) Ok... bad joke.
C-3. Non-Numeric Version to Release
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric versioned packages can be problematic so they must be treated with care. These are cases where the upstream version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before or after the number. Read section B to understand why we cannot simply put these letters into the version tag.
Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} Release Tag for Non-Numeric Post-Release Packages: %{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that came from the version.
Example (pre-release): mozilla-1.4a.tar.gz from usptream is lower than mozilla-1.4.tar.gz the later "final" version thus mozilla-1.4-0.1.a Fedora package name
Example (pre-release): alsa-lib-0.9.2beta1.tar.gz becomes alsa-lib-0.9.2-0.1.beta1
Example (post-release): gkrellm-2.1.7.tar.gz gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7 gkrellm-2.1.7-1.a
For gkrellm is this necessary? rpm considers 2.1.7a newer than 2.1.7 already unless something has changed. Another package of this nature is UW imap. It is generally released with an integer based version number of the year of it's release, possibly followed by a single letter indicating a revision within that year. ie: imap-2000 imap-2000a imap-2000b
In rpm's normal operation these packages are naturally treated as the older package on the left, with the newer ones proceeding to the right.
My personal preference would be to just let rpm assume that as it should work. I've never gotten bug reports of it not working anyway. Moving things from the version to the release field unnecessarily just complicates packaging when there's no real benefit IMHO. For the pre-release cases above it makes sense as it's being done in order to override rpm's default behaviour, which would be to treat what is a final release as older than a prerelease.
I believe treating both pre-release and post-release in the same manner just for consistency with both types of lettered versioned packages is just cosmetic consistency, but doesn't provide any functional or technical benefit. In other words, sticking with the upstream version in the version field is IMHO best unless there is a technical benefit of doing so, such as avoiding having to later use Epoch to override a prerelease build.
Are there cases where rpm would consider imap-2000a as older than imap-2000?
jbj?
Err... you are completely right about it not being necessary in the post-release case. I am not sure why our fedora.us policy retained that even though it was unnecessary for all these months. The way I understand the older version of rpm broken rpmvercmp behavior, this wouldn't be a problem with those versions too.
C-4. Dist tag
In cases where the same SRPM and patchlevel is used between two or more distributions supported by Fedora, a dist tag is appended to the end of the release tag defined in C-2 and C-3. The dist tags with the following examples appear to be only cosmetic, however the a different E-V-R is needed between distributions to ensure dist upgrading works fully in all corner cases.
Dist Tag for Normal Packages: %{X}.%{disttag} Where %{X} is the vepoch and %{disttag} is a distribution tag from this table:
0.7.3 Red Hat Linux 7.3 0.8 Red Hat Linux 8 0.9 Red Hat Linux 9 1 Fedora Core 1 1.93 Fedora Core 1.93 beta 1.94 Fedora Core 1.94 beta 2 Fedora Core 2 beta
Example: foobar-1.2.3-1_0.7.3.i386.rpm foobar-1.2.3-1_0.8.i386.rpm foobar-1.2.3-1_0.9.i386.rpm foobar-1.2.3-1_1.94.i386.rpm foobar-1.2.3-1_2.i386.rpm
Upgrade Path Example (FC1 only shown): foobar-1.2.3-1_1.i386.rpm foobar-1.2.3-2_1.i386.rpm foobar-1.2.3-3_1.i386.rpm
Ick. Underscores in version/release are hideous IMHO. I'd use "." instead of "_". Your comment at the top of this section indicates a ".", so perhaps you just made a typo, and sequence of cut and paste errors? ;o)
Oops. Yeah, fedora.us original plan was ".", however some here on fedora-devel-list argued toward "_" as a more clear separator between the patchlevel and disttag because it can be confusing with so many "."
I personally actually prefer the "." separator, but I really don't care which is chosen.
Warren
Le ven 31/10/2003 à 15:31, Warren Togami a écrit :
Mike A. Harris wrote:
Ick. Underscores in version/release are hideous IMHO. I'd use "." instead of "_". Your comment at the top of this section indicates a ".", so perhaps you just made a typo, and sequence of cut and paste errors? ;o)
Oops. Yeah, fedora.us original plan was ".", however some here on fedora-devel-list argued toward "_" as a more clear separator between the patchlevel and disttag because it can be confusing with so many "."
I personally actually prefer the "." separator, but I really don't care which is chosen.
For the record, I think underscores are hideous too. That makes it three people that commented on this:)
Cheers,
On Fri, 2003-10-31 at 17:47, Nicolas Mailhot wrote:
Le ven 31/10/2003 à 15:31, Warren Togami a écrit :
Mike A. Harris wrote:
Ick. Underscores in version/release are hideous IMHO. I'd use "." instead of "_". Your comment at the top of this section indicates a ".", so perhaps you just made a typo, and sequence of cut and paste errors? ;o)
Oops. Yeah, fedora.us original plan was ".", however some here on fedora-devel-list argued toward "_" as a more clear separator between the patchlevel and disttag because it can be confusing with so many "."
I personally actually prefer the "." separator, but I really don't care which is chosen.
For the record, I think underscores are hideous too. That makes it three people that commented on this:)
Heh, why not make it @ .. it sorta even has a meaning "foo-1.2.3 at (==for) RHL 9": foobar-1.2.3-1@0.9.i386.rpm. Looks lovely doesn't it :)
<ducks and runs>
- Panu -
I personally actually prefer the "." separator, but I really don't care which is chosen.
For the record, I think underscores are hideous too. That makes it three people that commented on this:)
I hate me too posts... But... aw heck... me too...
-Chuck
On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
C-3. Non-Numeric Version to Release
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric versioned packages can be problematic so they must be treated with care. These are cases where the upstream version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before or after the number. Read section B to understand why we cannot simply put these letters into the version tag.
Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} Release Tag for Non-Numeric Post-Release Packages: %{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that came from the version.
Example (pre-release): mozilla-1.4a.tar.gz from usptream is lower than mozilla-1.4.tar.gz the later "final" version thus mozilla-1.4-0.1.a Fedora package name
Example (pre-release): alsa-lib-0.9.2beta1.tar.gz becomes alsa-lib-0.9.2-0.1.beta1
Example (post-release): gkrellm-2.1.7.tar.gz gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7 gkrellm-2.1.7-1.a
For gkrellm is this necessary? rpm considers 2.1.7a newer than 2.1.7 already unless something has changed. Another package of this nature is UW imap. It is generally released with an integer based version number of the year of it's release, possibly followed by a single letter indicating a revision within that year. ie: imap-2000 imap-2000a imap-2000b
In rpm's normal operation these packages are naturally treated as the older package on the left, with the newer ones proceeding to the right.
My personal preference would be to just let rpm assume that as it should work. I've never gotten bug reports of it not working anyway. Moving things from the version to the release field unnecessarily just complicates packaging when there's no real benefit IMHO. For the pre-release cases above it makes sense as it's being done in order to override rpm's default behaviour, which would be to treat what is a final release as older than a prerelease.
I believe treating both pre-release and post-release in the same manner just for consistency with both types of lettered versioned packages is just cosmetic consistency, but doesn't provide any functional or technical benefit. In other words, sticking with the upstream version in the version field is IMHO best unless there is a technical benefit of doing so, such as avoiding having to later use Epoch to override a prerelease build.
Are there cases where rpm would consider imap-2000a as older than imap-2000?
jbj?
Err... you are completely right about it not being necessary in the post-release case. I am not sure why our fedora.us policy retained that even though it was unnecessary for all these months. The way I understand the older version of rpm broken rpmvercmp behavior, this wouldn't be a problem with those versions too.
* To be able to go back from 2.1.7a to a patched 2.1.7 in case the 2.1.7a post-release "fix" turns out to cause side-effects.
* Consistency above all.
* The road of least surprise (with regard to upstream versioning).
* To help avoid that users think foo-1.0a would be an unstable alpha version, when in fact it is a post-release patch-level.
--
On Fri, 2003-10-31 at 19:00, Michael Schwendt wrote:
On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
Err... you are completely right about it not being necessary in the post-release case. I am not sure why our fedora.us policy retained that even though it was unnecessary for all these months. The way I understand the older version of rpm broken rpmvercmp behavior, this wouldn't be a problem with those versions too.
To be able to go back from 2.1.7a to a patched 2.1.7 in case the 2.1.7a post-release "fix" turns out to cause side-effects.
Consistency above all.
The road of least surprise (with regard to upstream versioning).
To help avoid that users think foo-1.0a would be an unstable alpha version, when in fact it is a post-release patch-level.
Also, if foo-1.0a < foo-1.0b < foo-1.0a, as presented earlier in the proposal (the "two-way upgrade problem") exists for prereleases, why wouldn't it exist for postreleases?
On Fri, 2003-10-31 at 07:55, Ville Skyttä wrote:
On Fri, 2003-10-31 at 19:00, Michael Schwendt wrote:
On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
Err... you are completely right about it not being necessary in the post-release case. I am not sure why our fedora.us policy retained that even though it was unnecessary for all these months. The way I understand the older version of rpm broken rpmvercmp behavior, this wouldn't be a problem with those versions too.
To be able to go back from 2.1.7a to a patched 2.1.7 in case the 2.1.7a post-release "fix" turns out to cause side-effects.
Consistency above all.
The road of least surprise (with regard to upstream versioning).
To help avoid that users think foo-1.0a would be an unstable alpha version, when in fact it is a post-release patch-level.
Also, if foo-1.0a < foo-1.0b < foo-1.0a, as presented earlier in the proposal (the "two-way upgrade problem") exists for prereleases, why wouldn't it exist for postreleases?
Actually, the two-way upgrade problem was fixed right before RH9. So rpm-4.2 in RH9, rpm-4.2.1, rpm-4.1.1, rpm-4.0.5 all behave properly in this case.
This however does not matter, since it has been agreed upon on fedora-legacy list that ALL distributions supported by Fedora Legacy will force an upgrade of rpm as a requirement for users to begin using those repositories. This is in order to enforce consistency and avoid old bugs that were fixed ages ago. (A tremendous amount of verification testing will happen before each rpm is published for Legacy.)
Warren
On Fri, Nov 07, 2003 at 01:27:20AM -1000, Warren Togami wrote:
This however does not matter, since it has been agreed upon on fedora-legacy list that ALL distributions supported by Fedora Legacy will force an upgrade of rpm as a requirement for users to begin using those repositories.
When was this agreed upon?
While I personally support this scheme, I was under the impression that there were more people against enforcing rpm upgrades for minimally changes (e.g. fedora-legacy should only provide security related errata). Especially because RH itself did not issue errata for rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm upgrades, so unless we are the only left subscribers of fedora-legacy, it is not yet an agreement of the whole list. ;)
On Friday 07 November 2003 08:47, Axel Thimm wrote:
While I personally support this scheme, I was under the impression that there were more people against enforcing rpm upgrades for minimally changes (e.g. fedora-legacy should only provide security related errata). Especially because RH itself did not issue errata for rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm upgrades, so unless we are the only left subscribers of fedora-legacy, it is not yet an agreement of the whole list. ;)
I personally agreed to it, until somebody showed me clear evidence that it could/would break something.
Le ven 07/11/2003 à 17:59, Jesse Keating a écrit :
On Friday 07 November 2003 08:47, Axel Thimm wrote:
While I personally support this scheme, I was under the impression that there were more people against enforcing rpm upgrades for minimally changes (e.g. fedora-legacy should only provide security related errata). Especially because RH itself did not issue errata for rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm upgrades, so unless we are the only left subscribers of fedora-legacy, it is not yet an agreement of the whole list. ;)
I personally agreed to it, until somebody showed me clear evidence that it could/would break something.
I supported it too I wasn't the only one. Is this "me too thread" really useful ? Did anyone propose an alternative scheme that had any chance to work ?
Cheers,
On Fri, 2003-11-07 at 20:59, Nicolas Mailhot wrote:
Le ven 07/11/2003 à 17:59, Jesse Keating a écrit :
On Friday 07 November 2003 08:47, Axel Thimm wrote:
While I personally support this scheme, I was under the impression that there were more people against enforcing rpm upgrades for minimally changes (e.g. fedora-legacy should only provide security related errata). Especially because RH itself did not issue errata for rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm upgrades, so unless we are the only left subscribers of fedora-legacy, it is not yet an agreement of the whole list. ;)
I personally agreed to it, until somebody showed me clear evidence that it could/would break something.
I supported it too I wasn't the only one. Is this "me too thread" really useful ? Did anyone propose an alternative scheme that had any chance to work ?
More importantly (IMHO, YMMV): what does that imply, if anything, related to the naming guidelines?
There was some support for moving/keeping non-numeric upstream post-release version parts in %{version} instead of moving them into %{release}, what is the consensus on that now?
On Friday 07 November 2003 13:17, Ville Skyttä wrote:
There was some support for moving/keeping non-numeric upstream post-release version parts in %{version} instead of moving them into %{release}, what is the consensus on that now?
Please see Warren Togami's naming scheme proposal. Unless otherwise opposed, Fedora Legacy will adopt this naming scheme and move forward with it.
On Fri, 7 Nov 2003, Axel Thimm wrote:
This however does not matter, since it has been agreed upon on fedora-legacy list that ALL distributions supported by Fedora Legacy will force an upgrade of rpm as a requirement for users to begin using those repositories.
When was this agreed upon?
While I personally support this scheme, I was under the impression that there were more people against enforcing rpm upgrades for minimally changes (e.g. fedora-legacy should only provide security related errata). Especially because RH itself did not issue errata for rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm upgrades, so unless we are the only left subscribers of fedora-legacy, it is not yet an agreement of the whole list. ;)
Make it 3 then... I support Warren's suggestion. Perhaps others will speak up too if it is something up for democratic vote. If it's not up for democratic vote, hail Warren!
On Friday 07 November 2003 12:06, Mike A. Harris wrote:
Make it 3 then... I support Warren's suggestion. Perhaps others will speak up too if it is something up for democratic vote. If it's not up for democratic vote, hail Warren!
Well, I think right now I'd have the final say, but I do differ to warren on a lot of issues. I'd have to dig up some old email, but there were some locking bugs and upgrade version issues that we wanted to solve with a single rpm version set across all the supported Legacy distros. Fedora.us has done a lot of research on it so I've been told, and they haven't found any reason to not fix these nasty bugs.
So I'm going to be a bit totalitarian for a moment, and unless somebody can show me a really good reason to _not_ fix RPM across these release, then rpm will be upgraded.
Note, this is not an upgrade just to upgrade, we're fixing bugs here.
On Friday 07 November 2003 03:06 pm, Mike A. Harris wrote:
Make it 3 then... I support Warren's suggestion. Perhaps others will speak up too if it is something up for democratic vote. If it's not up for democratic vote, hail Warren!
4. I mentioned the fact that Red Hat had already set the precedent back with some errata packages for RPM with RHL 6.2, 7, and others.
By way of introduction, since everyone else is doing them, my qualifications, etc, are as follows...
I have maintained the PostgreSQL RPMset since July of 1999, and had my RPM work includedby Red Hat as part of RHL 6.1. I have built various other RPMs for my use, and have provided a few for other projects over the years, including the BibleTime SWORD project KDE reader. I have actively used and developed on Red Hat Linux since version 4.1 in April 1997. I am one of the few enterprise users of the Aurora Linux distribution on a network of UltraSPARCs at PARI. I have operated an internet radio site (on Red Hat Linux and RealAudio) since May 1997. I have recovered from a root compromise. I currently maintain the AOLserver PostgreSQL driver.
And I of course try to show the benefits of Linux and open source at every opportunity to every one.
A couple of things about me that are rather unusual among open source people is that I am a duly ordained Baptist minister and am a professor at Anchor Baptist Bible College, teaching English amongst other courses.
On Fri, Nov 07, 2003 at 05:47:17PM +0100, Axel Thimm wrote:
On Fri, Nov 07, 2003 at 01:27:20AM -1000, Warren Togami wrote:
This however does not matter, since it has been agreed upon on fedora-legacy list that ALL distributions supported by Fedora Legacy will force an upgrade of rpm as a requirement for users to begin using those repositories.
When was this agreed upon? [...] so unless we are the only left subscribers of fedora-legacy, it is not yet an agreement of the whole list. ;)
Am I the only one that finds it questionable that assertions like these are simply being made?
Even if the whole list and the world agrees postscriptum (which it doesn't), what kind of tacticts are these? There was clearly not a list agreement (set aside if there is need for one), so why present your opinion as the list's?
Did I mention that it was agreed upon all fedora-lists to remove glibc from ALL distributions?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 08 November 2003 04:20, Axel Thimm wrote:
Am I the only one that finds it questionable that assertions like these are simply being made?
Even if the whole list and the world agrees postscriptum (which it doesn't), what kind of tacticts are these? There was clearly not a list agreement (set aside if there is need for one), so why present your opinion as the list's?
Did I mention that it was agreed upon all fedora-lists to remove glibc from ALL distributions?
Alex, calm down. It has been proposed, then modified slightly (which I forgot) by Warren, to just upgrade to the latest that rpm.org has to offer for each respective os. There were reasons posted as well. At the time, nobody seemed to oppose it. Now there seems to be some opposition. No need to get your feathers ruffled, we can discuss it once more. We have until mid December to make some decisions.
- -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
-- fedora-legacy-list mailing list fedora-legacy-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list
On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote:
On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
[...]
Are there cases where rpm would consider imap-2000a as older than imap-2000?
jbj?
Err... you are completely right about it not being necessary in the post-release case. I am not sure why our fedora.us policy retained that even though it was unnecessary for all these months. The way I understand the older version of rpm broken rpmvercmp behavior, this wouldn't be a problem with those versions too.
- To be able to go back from 2.1.7a to a patched 2.1.7 in case the 2.1.7a post-release "fix" turns out to cause side-effects.
Hmm I'm not sure if I buy that -- extrapolating form that, one should also be able to go back from 2.1.8 to 2.1.7 in case the new version turns out to cause side-effects (without any "--oldpackages" stuff or that point is moot). We could also set the version to "1" for all packages and use only serial numbers for releases -- that way updating always works ;-).
I think the version should always be the upstream version where these are not incompatible with RPM version comparisons and real version numbers (and not CVS dates or the like because they may be substituted with real version numbers which are likley less RPM wise) and (optional) characters represent newer patch levels (and not prereleases). If that version number contains dashes, replacing them with underscores might be necessary.
- Consistency above all.
Care to explain that one? Of course the idea I have about versioning seems most consistent to me but I'm sure you can shed some light on why version numbers differing from upstream are more consistent ;-).
- The road of least surprise (with regard to upstream versioning).
That's what I want.
- To help avoid that users think foo-1.0a would be an unstable alpha version, when in fact it is a post-release patch-level.
I do not think that is the purpose of an RPM version tag. It exists so the user knows that this is the upstream version number-- how else would a user be able to submit bug reports upstream if he cannot supply the real version number/string/whatever. If users interpret version strings like "1.0a" as an alpha version when they're not -- well, that's tough luck but nothing that should be worked around by some RPM version trickeries.
Nils
On Sat, 01 Nov 2003 12:21:59 +0100, Nils Philippsen wrote:
On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote:
On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
[...]
Are there cases where rpm would consider imap-2000a as older than imap-2000?
jbj?
Err... you are completely right about it not being necessary in the post-release case. I am not sure why our fedora.us policy retained that even though it was unnecessary for all these months. The way I understand the older version of rpm broken rpmvercmp behavior, this wouldn't be a problem with those versions too.
- To be able to go back from 2.1.7a to a patched 2.1.7 in case the 2.1.7a post-release "fix" turns out to cause side-effects.
Hmm I'm not sure if I buy that -- extrapolating form that, one should also be able to go back from 2.1.8 to 2.1.7 in case the new version turns out to cause side-effects (without any "--oldpackages" stuff or that point is moot).
That would be something different, since I assume 2.1.8 comes quite some time after 2.1.7. On the contrary, 2.1.7a would be sort of a quick brown paperbag fix attempt which would be released shortly after 2.1.7, often just a few hours later or on the same day. Including such an upstream fix prior to publishing a package is tempting, and sometimes it turns out right after release that the fix breaks other parts of the software in an unexpected way and the real fix takes more time.
I'd a fan of serial numbers, but not when they're hidden. I would even like a scheme like
name.serial.upstreamversion.arch.rpm
I think the version should always be the upstream version where these are not incompatible with RPM version comparisons and real version numbers (and not CVS dates or the like because they may be substituted with real version numbers which are likley less RPM wise) and (optional) characters represent newer patch levels (and not prereleases). If that version number contains dashes, replacing them with underscores might be necessary.
Not "might be necessary", it is a strict requirement by RPM.
- Consistency above all.
Care to explain that one? Of course the idea I have about versioning seems most consistent to me but I'm sure you can shed some light on why version numbers differing from upstream are more consistent ;-).
Since you understand the need for a pre-release version/release modification guideline, you do understand this guideline very well, too, and hence it doesn't need much of an explanation IMO.
- The road of least surprise (with regard to upstream versioning).
That's what I want.
- To help avoid that users think foo-1.0a would be an unstable alpha version, when in fact it is a post-release patch-level.
I do not think that is the purpose of an RPM version tag. It exists so the user knows that this is the upstream version number-- how else would a user be able to submit bug reports upstream if he cannot supply the real version number/string/whatever.
The user should find the software version number in the "About" or "Help" sections, in the manual and should never rely on package versioning. E.g. KDE 3.1.4-6 is not an upstream version, GCC 2.96 wasn't either. Now don't tell me all users know what the release version is. Why should it be allowed (or make sense) to modify 1.0rc3-2 to 1.0-2.rc3, but not 1.0pl1-2 to 1.0-2.pl1?
If users interpret version strings like "1.0a" as an alpha version when they're not -- well, that's tough luck but nothing that should be worked around by some RPM version trickeries.
It's not a primary goal, but it helps. It should not be user's responsibility to know that Mozilla 1.5a is older than 1.5, but Foo 1.5a is a bug-fix release for Foo 1.5. The package release version should make that obvious. Else user keeps using the unstable Mozilla 1.5a as long as rpmseek.com doesn't list a newer version.
I don't like the dependency on upstream versioning at all, cases such as 1.01 > 1.0.2, 0.6 > 0.50, 0.010 > 0.1, 1.2 < 1.02, 1.0a < 1.0 or 1.0a > 1.0, ... not all can be dealt with without modifying these version numbers.
--
On Fri, 31 Oct 2003, Warren Togami wrote:
Just a personal opinion that this might confuse people, and if a better name can be chosen that is short enough and clear, it might be better.
Hmmm, I am in agreement. While we fedora.us people had no problem with vepoch for many months, I can see where it is confusing. I designed the name to be "Kind of like epoch, vepoch trumps all, but less."
Perhaps "patchlevel" is a better word.
I'm not sure patchlevel gives the right visual either.. It implies something to do with the number of patches being applied, or the version of a patch or something.
I strongly agree with this approach. Probably because I stole it from bero, and I think you picked it up from me or from bero also. ;o) It works very well IMHO. It's also very useful with CVS based releases where you can embed the CVS date into the release field instead of the version field, thus avoiding having to use Epoch later on to override the large integer release number from a CVS date.
Yes, when I originally designed this method I was pointing at bero's packages as justification. "See! Look, Red Hat did it!"
Yeah, this is a very good way to work around a not uncommon problem.
Err... you are completely right about it not being necessary in the post-release case. I am not sure why our fedora.us policy retained that even though it was unnecessary for all these months. The way I understand the older version of rpm broken rpmvercmp behavior, this wouldn't be a problem with those versions too.
Ah. RHL 7.2 shipped with rpm-4.0.3-1.03, and 7.3 shipped with rpm-4.0.4-7x.18, both of which don't have this problem. rpm 4.0.4 is the current erratum for all distribution releases from RHL 7.0 and later (or a newer version of rpm). Older versions aparently did have the problem according to other mails I received, but I think it's safe to say that distro releases supported by Fedora are unaffected, and that at least as far back as a properly updated 7.0 system should also be unaffected.
RHL 6.2 seems to have an older rpm version which may or may not be affected, but I think that's outside the care zone. ;o)
Ick. Underscores in version/release are hideous IMHO. I'd use "." instead of "_". Your comment at the top of this section indicates a ".", so perhaps you just made a typo, and sequence of cut and paste errors? ;o)
Oops. Yeah, fedora.us original plan was ".", however some here on fedora-devel-list argued toward "_" as a more clear separator between the patchlevel and disttag because it can be confusing with so many "."
Hmm. Good point. Perhaps it just needs some getting used to.
I personally actually prefer the "." separator, but I really don't care which is chosen.
I suppose if it's a useful thing to people that we should keep an open mind about it, even if it is ugly. ;o)
On Fri, Oct 31, 2003 at 07:58:46AM +0100, Axel Thimm wrote:
==================== Disttag schemes: pick one!
Here are the discussed schemes (some others exist with small variations, e.g. fc instead of fdr, or no fdr tag at all, the discussion is the same). Default versioning is (no cvs/beta, kernel modules and special cases, leave that for another thread):
<name>-<upstream version>-<releasenumber><disttag><non sort relevant suffixes, e.g. repoid> e.g. simply foo-1.2.3-4.<disttag>.johnsmith
disttag can be: A B C Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3 Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0 Red Hat Linux 9 fdr0.9 rh9 rh9 Fedora Core 1 fdr1 rh9.1 1fdr Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr
On Thu, Oct 30, 2003 at 10:53:03PM -1000, Warren Togami wrote:
Just to be 100% clear I am soon posting my revised package naming counter-proposal for fedora.redhat.com.
On Thu, Oct 30, 2003 at 11:22:27PM -1000, Warren Togami wrote:
Dist Tag for Normal Packages: %{X}.%{disttag} Where %{X} is the vepoch and %{disttag} is a distribution tag from this table:
0.7.3 Red Hat Linux 7.3 0.8 Red Hat Linux 8 0.9 Red Hat Linux 9 1 Fedora Core 1 1.93 Fedora Core 1.93 beta 1.94 Fedora Core 1.94 beta 2 Fedora Core 2 beta
So this is scheme A, with the variation of dropping the distid.
On Fri, 2003-10-31 at 04:22, Warren Togami wrote:
Example: foobar-1.0a foobar-1.0b
The "1.0b" version is higher than "1.0a", but all versions of RPM prior to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever package is first in the comparison "wins", thus this becomes a two way upgrade problem. This a < b comparison works properly only in RH9 and higher.
a < b has worked in RPM from day one. The only issue in rpm's version comparison function was comparing a letter to a number, for example 1.a vs 1.1. All versions of rpm would get the example right.
Thanks. Peter
-
Axel Thimm -
Chuck Wolber -
Jesse Keating -
Lamar Owen -
Michael Schwendt -
Mike A. Harris -
Nicolas Mailhot -
Nils Philippsen -
Panu Matilainen -
Peter Bowen -
Ville Skyttä -
Warren Togami