5:26 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is known yet what will happen to /etc/redhat-release?
In case the 2nd Severn Beta will be the first Fedora Core "test"
release, will /etc/redhat-release be gone already and reappear as
/etc/fedora-release?
Sort of
$ cat /etc/fedora-release
Fedora Core release 0.90.94 (Severn)
or similar? Or will there be a different transition?
Any known details would be interesting in order to prepare some
src.rpms in Fedora.us's Severn repository for Cambridge.
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/cMik0iMVcrivHFQRAj6GAJoC2iiPUGkpBomgLnYtBJ5UCy3G7ACffma2
TrM3jChftfTtzwwTUVClpRM=
=ljtj
-----END PGP SIGNATURE-----
5:45 p.m.
Michael Schwendt (ms-nospam-0306(a)arcor.de) said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is known yet what will happen to /etc/redhat-release?
In case the 2nd Severn Beta will be the first Fedora Core "test"
release, will /etc/redhat-release be gone already and reappear as
/etc/fedora-release?
Not just yet.
The final solution will probably be:
package: fedora-release
provides: redhat-release
Has a /etc/fedora-release and an /etc/redhat-release symlink.
The second test release will just have a redhat-release package
that has "Fedora Core" in the name. Didn't want to break things
just yet. :)
Bill
6:17 p.m.
What about the versioning? Will xxx-release continue to have
rpm-monotonic larger VRs than the previous releases?
Some repositories use the version of redhat-release package to form
tags ensuring rpm-safe upgrade paths from previous RH releases (which
wouldn't be a bad policy for RH itself).
--
Axel.Thimm(a)physik.fu-berlin.de
2:45 a.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Tue, Sep 23, 2003 at 07:28:58PM -0400, Elliot Lee wrote:
On Wed, 24 Sep 2003, Axel Thimm wrote:
> What about the versioning? Will xxx-release continue to have
> rpm-monotonic larger VRs than the previous releases?
EpochVR yes, VR no.
The beta will have redhat-release-0.94-1 (epoch 1).
That is ugly in multiple ways. Leaving all other reasons for not
using epochs aside, this will break all upgrade paths from embedded
disttags like 7.3, 8.0 or 9. The logical conduction would be to have
these repos also bump up epochs to ensure rpm upgradability or invent
their own versioning.
Any way it will be creating confusion and disorder. ;)
Could a better mechanism be created before the 25th that enables
disttags to be carried on? Please use no epoch/release, and make the
version be (rpm-)bigger than "9". Also keep redhat-release as a proper
package carrying that version information.
Background:
===========
Up to now RH was not often in the need to release multiple versions of
the same package for different RH releases. Even if the package did
not change its release tag was bumbed (rebuilt for xxx).
Errata were either based on different upstream sources, so no upgrade
clashes could come up, while in the very rare cases, where exactly the
same package was rebuilt for different RH release the package
maintainer had to invent a scheme that worked in that timeframe
(e.g. the kernel errata releases for RH 7.3/8.0/9).
3rd party repos have been using the idiom of keeping the same upstream
release current in multiple RH releases more often. The only portable
way up to now to do so was to inspect the rpm-version value of
redhat-release. Tags were created like
foo-fooversion-foorelease.rh8.0.i386.rpm
etc., ensuring sane upgrade paths for users of the 3rd party
repo. Here are some google pointers:
http://www.google.com/search?q=rpm+%22--qf%22+version+redhat-release
My plea is therefore to
o keep redhat-release as a package of its own, so that
`rpm -q --qf "%{VERSION}" redhat-release' still works.
o Make the version of this package rpm-monotonic without using epoch
(or even release tags), e.g. use a version rpm-larger than "9".
o Put redhat-release into rawhide carrying the anaconda version ...
The alternative is to break the upgrade path mechanism of several
repos or single package sites, please don't.
--
Axel.Thimm(a)physik.fu-berlin.de
5:57 a.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wed, 2003-09-24 at 03:45, Axel Thimm wrote:
That is ugly in multiple ways. Leaving all other reasons for not
using epochs aside, this will break all upgrade paths from embedded
disttags like 7.3, 8.0 or 9. The logical conduction would be to have
these repos also bump up epochs to ensure rpm upgradability or invent
their own versioning.
o keep redhat-release as a package of its own, so that
`rpm -q --qf "%{VERSION}" redhat-release' still works.
o Make the version of this package rpm-monotonic without using epoch
(or even release tags), e.g. use a version rpm-larger than "9".
o Put redhat-release into rawhide carrying the anaconda version ...
First, I would encourage you, and anyone else doing something like this
to strongly consider doing 'rpm -qf --qf "%{VERSION}"
/etc/redhat-release', as checking for the redhat-release package will
fail on RHEL.
Second, it shouldn't be a big deal to come up with a versioning scheme
that will satisfy your needs. Epochs are definitely not the answer.
Your best bet, if you require the new package to compare favorably
-18.rh80 would be to do -18.1fc, as that would be "newer" according to
rpm. Recent rpm versions always will sort a numeric character higher
than an alphabetic character.
Thanks.
Peter
1:16 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wed, 2003-09-24 at 03:57, Peter Bowen wrote:
First, I would encourage you, and anyone else doing something like
this
to strongly consider doing 'rpm -qf --qf "%{VERSION}"
/etc/redhat-release', as checking for the redhat-release package will
fail on RHEL.
I wish we could settle on a standard /etc/release that would encode
these things in a shell-friendly manner, like /etc/lsb-release does.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Naked Ape Consulting http://nakedape.cc *
1:33 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wed, Sep 24, 2003 at 06:57:38AM -0400, Peter Bowen wrote:
On Wed, 2003-09-24 at 03:45, Axel Thimm wrote:
> That is ugly in multiple ways. Leaving all other reasons for not
> using epochs aside, this will break all upgrade paths from embedded
> disttags like 7.3, 8.0 or 9. The logical conduction would be to have
> these repos also bump up epochs to ensure rpm upgradability or invent
> their own versioning.
>
> o keep redhat-release as a package of its own, so that
> `rpm -q --qf "%{VERSION}" redhat-release' still works.
> o Make the version of this package rpm-monotonic without using epoch
> (or even release tags), e.g. use a version rpm-larger than "9".
> o Put redhat-release into rawhide carrying the anaconda version ...
First, I would encourage you, and anyone else doing something like this
to strongly consider doing 'rpm -qf --qf "%{VERSION}"
/etc/redhat-release', as checking for the redhat-release package will
fail on RHEL.
Thanks for the tip. (I wouldn't like to put RHEL packages in the same
upgrade path line as rh/fc packages, so I would poll the version
explicitely from the corresponding rpm file and use a different
disttag alltogether like rhel3).
Second, it shouldn't be a big deal to come up with a versioning
scheme
that will satisfy your needs. Epochs are definitely not the answer.
Your best bet, if you require the new package to compare favorably
-18.rh80 would be to do -18.1fc,
This would rather read
-18.1fc0.94
(or whatever the fc release might be). Adding the usual repo id tag,
you land at
-18.1fc0.94.at
This my-release-tag-is-longer-than-your-release-tag madness must
stop. It will push repo maintainers to either drop upgrade paths, or
to come up with different versioning, e.g. rh10, to keep their repo
structure intakt.
as that would be "newer" according to rpm. Recent rpm
versions
always will sort a numeric character higher than an alphabetic
character.
Which is also another problem with upgrade paths as the starting
release may have the toggling alphanumeric rpm bug (I think anything
<= rpm-4.1, so at least the whole 7.x series is affected - not that is
really makes sense to jump from 7.x to current rh/fc/rawhide).
--
Axel.Thimm(a)physik.fu-berlin.de
1:43 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
How many packages actually *need* these different disttags? I can
usually install packages for RH8 just fine on Rawhide, even tho most of
the underlying software has newer packages.
I'd wager only a handful of packages really rely on the core OS
version. Most probably rely on other packages, i.e., GNOME - a GNOME
app shouldn't depend on RH8 for GNOME2 and RH9 for GNOME2.2 and FC1 for
GNOME2.4 - it should just depend on the GNOME version. After all, an
app made for GNOME2.0 will work just fine on GNOME2.4, and thus RH8
GNOME apps should run on FC1 no problem.
Instead of hacking up the distro's cleanliness to support poor packaging
practices, maybe the packaging practices should just be corrected...
(I'll admit I could easily be missing some piece of the puzzle - if I'm
babbling in such a way, have my apologies for being clueless ^^; )
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
1:08 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wed, 2003-09-24 at 00:45, Axel Thimm wrote:
Could a better mechanism be created before the 25th that enables
disttags to be carried on? Please use no epoch/release, and make the
version be (rpm-)bigger than "9". Also keep redhat-release as a proper
package carrying that version information.
I see no reason not to continue incrementing the version number from
"Red Hat Linux" and just use 10. Yes, there have been big changes with
changing the name to Fedora Linux and changing the development model
from a commerical product to a community project, but it isn't a totally
new distribution and the versioning shouldn't start from zero.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
1:27 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
Axel Thimm (Axel.Thimm(a)physik.fu-berlin.de) said:
> The beta will have redhat-release-0.94-1 (epoch 1).
That is ugly in multiple ways. Leaving all other reasons for not
using epochs aside, this will break all upgrade paths from embedded
disttags like 7.3, 8.0 or 9.
It's a new release model, hence a new release number. Fedora Core 10
doesn't make sense.
Also keep redhat-release as a proper
package carrying that version information.
The package will still provide redhat-release, use that. Obviously
you haven't tried to build packages for Red Hat Enterprise Linux. :)
Bill
3:12 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wed, Sep 24, 2003 at 02:27:23PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm(a)physik.fu-berlin.de) said:
> > The beta will have redhat-release-0.94-1 (epoch 1).
>
> That is ugly in multiple ways. Leaving all other reasons for not
> using epochs aside, this will break all upgrade paths from embedded
> disttags like 7.3, 8.0 or 9.
It's a new release model, hence a new release number. Fedora Core 10
doesn't make sense.
It does, if you want to retain upgrade paths ...
> Also keep redhat-release as a proper package carrying that
version
> information.
The package will still provide redhat-release, use that. Obviously
you haven't tried to build packages for Red Hat Enterprise Linux. :)
Do I hear someone willing to fund a license? ;)
--
Axel.Thimm(a)physik.fu-berlin.de
3:34 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
Axel Thimm (Axel.Thimm(a)physik.fu-berlin.de) said:
> It's a new release model, hence a new release number. Fedora
Core 10
> doesn't make sense.
It does, if you want to retain upgrade paths ...
What do you mean by 'upgrade paths'? All packages provided in the
release, sort newer-or-equal, in the method used by all sane upgrade
tools (E:V-R). So, I don't see how we're not retaining an upgrade
path.
Bill
5:39 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wed, Sep 24, 2003 at 04:34:50PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm(a)physik.fu-berlin.de) said:
> > It's a new release model, hence a new release number. Fedora Core 10
> > doesn't make sense.
>
> It does, if you want to retain upgrade paths ...
What do you mean by 'upgrade paths'? All packages provided in the
release, sort newer-or-equal, in the method used by all sane upgrade
tools (E:V-R). So, I don't see how we're not retaining an upgrade
path.
This has not to do with fc isolated, but with the supporting 3rd party
repos. It was discussed further up this thread, but I will rephrase
with an example. There exist more than one repository building rpms
for several RH releases (say RH7.3, 8.0 and 9). In order to ensure
upgrade paths for the users of this repository the packages are being
called
foo-1.2.3-1.rh7.3.i386.rpm
foo-1.2.3-1.rh8.0.i386.rpm
foo-1.2.3-1.rh9.i386.rpm
or similar variations like omitting the "rh" etc. Upgrades from one RH
release with enabled repo to another were thus safe.
Just to give more food for thought: How would you version a kernel
based on the same sources released for RH 7.x,8.0,9 and now
additionally fc?
kernel-2.4.22-1.2082.7.i686.rpm
kernel-2.4.22-1.2082.8.i686.rpm
kernel-2.4.22-1.2082.9.i686.rpm
kernel-2.4.22-1.2082.0.94.i686.rpm
The latter looses. You either have to rethink the first three or
version the last with something rpm-higher than "9". Or start epochin
all such packages occuring on multiple releases, which for somerpeos
means all of the carried packages.
You cannot save the above scheme with epochs. See the previous
messages in the thread with the "Background" information to see why
this didn't hit RH so often in the past, but possibly will do yo
rather often with shorter release cycles.
Or one decides to not support upgrade from older RH releases
concerning non-RH repos, which would be unfortunate.
--
Axel.Thimm(a)physik.fu-berlin.de
5:45 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wednesday 24 September 2003 15:39, Axel Thimm wrote:
The latter looses. You either have to rethink the first three or
version the last with something rpm-higher than "9". Or start epochin
all such packages occuring on multiple releases, which for somerpeos
means all of the carried packages.
Or you physically segment your updates directories.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
5:58 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
Axel Thimm (Axel.Thimm(a)physik.fu-berlin.de) said:
Just to give more food for thought: How would you version a kernel
based on the same sources released for RH 7.x,8.0,9 and now
additionally fc?
kernel-2.4.22-1.2082.7.i686.rpm
kernel-2.4.22-1.2082.8.i686.rpm
kernel-2.4.22-1.2082.9.i686.rpm
kernel-2.4.22-1.2082.0.94.i686.rpm
The latter looses. You either have to rethink the first three or
version the last with something rpm-higher than "9". Or start epochin
all such packages occuring on multiple releases, which for somerpeos
means all of the carried packages.
'loses', not 'looses'. :)
You're arguing, as best I can tell, that it will break on upgrading
some packages that haven't even been built yet, that are building
by some automated release-querying script, correct? Because, if
you're doing this versioning by hand, it's a non-starter. Anything
you're modifying by hand can be modified differently.
Such a script can be *easily* modifed to work with Fedora Core
in this case. It can key off of:
a) 'Fedora Core' in /etc/redhat-release
b) the presence of /etc/fedora-release
c) the fact that fedora-release provides /etc/redhat-release
Note that b) and c) will only be true in test release 3 and later.
Bill
1:01 a.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Wed, Sep 24, 2003 at 06:58:58PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm(a)physik.fu-berlin.de) said:
> Just to give more food for thought: How would you version a kernel
> based on the same sources released for RH 7.x,8.0,9 and now
> additionally fc?
>
> kernel-2.4.22-1.2082.7.i686.rpm
> kernel-2.4.22-1.2082.8.i686.rpm
> kernel-2.4.22-1.2082.9.i686.rpm
> kernel-2.4.22-1.2082.0.94.i686.rpm
>
> The latter looses. You either have to rethink the first three or
> version the last with something rpm-higher than "9". Or start epochin
> all such packages occuring on multiple releases, which for somerpeos
> means all of the carried packages.
'loses', not 'looses'. :)
You're arguing, as best I can tell, that it will break on upgrading
some packages that haven't even been built yet, that are building
by some automated release-querying script, correct?
No, this is current practice on several 3rd party repos for RedHat
including the one I maintain, as well as fedora itself ...
(See also the google link in my first post pointing to ~200 similar
sites)
Because, if you're doing this versioning by hand, it's a
non-starter. Anything you're modifying by hand can be modified
differently.
Well, I have heard of scripting before ...
Such a script can be *easily* modifed to work with Fedora Core
in this case. It can key off of:
a) 'Fedora Core' in /etc/redhat-release
b) the presence of /etc/fedora-release
c) the fact that fedora-release provides /etc/redhat-release
Note that b) and c) will only be true in test release 3 and later.
You are missing the point, the "script" is rpm/apt/yum/<your favourite
package resolver here>
Here is what is current practice for the upgraders (as opposed to
"freshinstallers"):
o Install RH8.0
o Install apt/yum
o Use repo A, B and C (pointing to its RH8.0 section)
o User decides to upgrade to RH9
o Upgrade the system with RH9 CDs
o Adjust the apt/yum configuration to the new version
o Update the system against the repos for RH9
There is no space for a custom script, unless you are thinking of
anaconda specials, which is not desired.
--
Axel.Thimm(a)physik.fu-berlin.de
4:10 a.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Thu, 2003-09-25 at 02:01, Axel Thimm wrote:
On Wed, Sep 24, 2003 at 06:58:58PM -0400, Bill Nottingham wrote:
> Such a script can be *easily* modifed to work with Fedora Core
> in this case. It can key off of:
>
> a) 'Fedora Core' in /etc/redhat-release
> b) the presence of /etc/fedora-release
> c) the fact that fedora-release provides /etc/redhat-release
>
> Note that b) and c) will only be true in test release 3 and later.
You are missing the point, the "script" is rpm/apt/yum/<your favourite
package resolver here>
Here is what is current practice for the upgraders (as opposed to
"freshinstallers"):
o Install RH8.0
o Install apt/yum
o Use repo A, B and C (pointing to its RH8.0 section)
o User decides to upgrade to RH9
o Upgrade the system with RH9 CDs
o Adjust the apt/yum configuration to the new version
o Update the system against the repos for RH9
There is no space for a custom script, unless you are thinking of
anaconda specials, which is not desired.
There is a space for custom scripts, in the spec generation process. It
is clear that you already have some custom script to help automate
building packages for all the different distro versions. Just modify
the script to look for one of the things that Bill mentioned, and either
internally add 9 to the version or do something else to cause rpmvercmp
to sort your EVR before the older EVR. No one is suggesting that
rpm/yum/up2date/anaconda/apt/red-carpet should be modified in any way.
Thanks.
Peter
3:09 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
Hi,
On Mi, 24 Sep 2003, Bill Nottingham sent incredible lines:
[...]
Such a script can be *easily* modifed to work with Fedora Core
in this case. It can key off of:
a) 'Fedora Core' in /etc/redhat-release
b) the presence of /etc/fedora-release
c) the fact that fedora-release provides /etc/redhat-release
[...]
why not /etc/release??
Fedora/Red Hat is part of the content of /etc/redhat-release. So I
don't see the sense of this construct but I see an advantage of
/etc/release if other distros will follow your this approach.
... may the Tux be with you! =Thomas=
--
Thomas Bendler \\:// ml(a)bendler-net.de
Mettlerkampsweg 21 (o -) http://www.bendler-net.de/
20535 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61
Germany Linux, enjoy the ride ...!
5:07 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Oct 13, 2003, Thomas Bendler <ml(a)bendler-net.de> wrote:
why not /etc/release??
One reason I can think of is that some random package for another
distro might fail to install because it happens to require a
<distro>-release package, that would then conflict with the original
<distro>-release should both of them try to install different
/etc/release files. I admit this is a convoluted scenario that I
don't think I've ever seen in practice. Besides, Requiring a specific
<distro>-release is probably bad practice anyway, so the packager
deserves the incompatibility (too bad it's the installer that gets
punished :-(
That said, I do like /etc/release, at least as a soft-link, maybe not
owned by RPM (to avoid the conflict described above)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
2:58 a.m.
New subject: Kind request: Set release version to "10" (was: Retain upgrade paths)
Before this thread vanishes into nirvana:
I'd like to kindly request to set to release version to "10" or
something higher than "9.0.94".
It would neither hurt marketing goals, nor any technical issues, but
it helps a lot with 3rd party repos supporting more than just the
latest release. Embedding (rpm-)increasing tags into the package
release ensures sane upgrade paths (similar to some Red Hat errata
releases like the kernel rpms). If you have questions on the technical
background follow up the thread.
If there isn't any compelling reason for setting the release version
to "1", please consider helping 3rd party repos with a sane release
version. After all part of the new open source movement is to better
support external developers and packagers.
Thank you.
On Thu, Sep 25, 2003 at 01:39:08AM +0300, Axel Thimm wrote:
This has not to do with fc isolated, but with the supporting 3rd
party
repos. It was discussed further up this thread, but I will rephrase
with an example. There exist more than one repository building rpms
for several RH releases (say RH7.3, 8.0 and 9). In order to ensure
upgrade paths for the users of this repository the packages are being
called
foo-1.2.3-1.rh7.3.i386.rpm
foo-1.2.3-1.rh8.0.i386.rpm
foo-1.2.3-1.rh9.i386.rpm
or similar variations like omitting the "rh" etc. Upgrades from one RH
release with enabled repo to another were thus safe.
Just to give more food for thought: How would you version a kernel
based on the same sources released for RH 7.x,8.0,9 and now
additionally fc?
kernel-2.4.22-1.2082.7.i686.rpm
kernel-2.4.22-1.2082.8.i686.rpm
kernel-2.4.22-1.2082.9.i686.rpm
kernel-2.4.22-1.2082.0.94.i686.rpm
The latter looses. You either have to rethink the first three or
version the last with something rpm-higher than "9". Or start epochin
all such packages occuring on multiple releases, which for somerpeos
means all of the carried packages.
--
Axel.Thimm(a)physik.fu-berlin.de
6:31 a.m.
New subject: Kind request: Set release version to "10" (was: Retain upgrade paths)
On Tue, 30 Sep 2003, Axel Thimm wrote:
It would neither hurt marketing goals, nor any technical issues, but
it helps a lot with 3rd party repos supporting more than just the
latest release. Embedding (rpm-)increasing tags into the package
release ensures sane upgrade paths (similar to some Red Hat errata
releases like the kernel rpms).
With the Epoch: (which went from 0 to 1 on the redhat-release package),
everything works out fine and is rpm-increasing.
-- Elliot
Individualists, unite!
4:12 a.m.
New subject: Kind request: Set release version to "10" (was: Retain upgrade paths)
On Tue, Sep 30, 2003 at 07:31:59AM -0400, Elliot Lee wrote:
On Tue, 30 Sep 2003, Axel Thimm wrote:
> It would neither hurt marketing goals, nor any technical issues, but
> it helps a lot with 3rd party repos supporting more than just the
> latest release. Embedding (rpm-)increasing tags into the package
> release ensures sane upgrade paths (similar to some Red Hat errata
> releases like the kernel rpms).
With the Epoch: (which went from 0 to 1 on the redhat-release package),
everything works out fine and is rpm-increasing.
You have to do it for each package in a multiple concurrent release
supporting repo that exists for multiple releases of RH. Read up this
thread for details and examples.
--
Axel.Thimm(a)physik.fu-berlin.de
6:56 a.m.
New subject: Kind request: Set release version to "10" (was: Retain upgrade paths)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 1 Oct 2003 12:12:47 +0300, Axel Thimm wrote:
> With the Epoch: (which went from 0 to 1 on the redhat-release
package),
> everything works out fine and is rpm-increasing.
You have to do it for each package in a multiple concurrent release
supporting repo that exists for multiple releases of RH. Read up this
thread for details and examples.
How many packages would that be? Consider the package naming scheme
of fedora.us which uses the following target release tags:
rh80 < rh90 < rh90.93 < 0.94
No problems during upgrades. The other example (kernel) doesn't hold
true for Fedora Core, because 0.94 contains a kernel version which is
higher than Red Hat Linux 9, 8.0 and older releases:
2.4.20-20.9 < 2.4.22-1.2061.nptl
2.4.20-20.8 < 2.4.22-1.2061.nptl
2.4.20-20.7 < 2.4.22-1.2061.nptl
Even if there were a kernel upgrade for RHL<=9, I'm sure it would see
a lower package release version than what is in Fedora Core, e.g.
2.4.22-2 in Fedora Core and 2.4.22-1.9 in Shrike Updates.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/esDo0iMVcrivHFQRAma9AJ94XrV9hWWlf9BbuhKRyhTiuHJ2OwCgiCxP
NkbVR5pA5sg/X6Pf9yexk9w=
=sniF
-----END PGP SIGNATURE-----
10 a.m.
New subject: Kind request: Set release version to "10"
On Wed, Oct 01, 2003 at 01:56:24PM +0200, Michael Schwendt wrote:
On Wed, 1 Oct 2003 12:12:47 +0300, Axel Thimm wrote:
> > With the Epoch: (which went from 0 to 1 on the redhat-release package),
> > everything works out fine and is rpm-increasing.
> You have to do it for each package in a multiple concurrent
> release supporting repo that exists for multiple releases of
> RH. Read up this thread for details and examples.
How many packages would that be?
How many? All the ones from my repo for instance. Same for other
repos. Some of the repos have intertwining dependencies that would
also need to be updated.
No, I won't enter that epoch hell, and probably neither will any other
repo maintainer.
Consider the package naming scheme of fedora.us which uses the
following target release tags:
rh80 < rh90 < rh90.93 < 0.94
That's a kludge (BTW it should have been rh8.0 < rh9 < rh9.0.93). What
about repos not using the rh tag and what about repos not willing to
give up identification of the rpm as belonging to the rh family? What
about Fedora Legacy, should part of it be distro-tagged and some not
(like your example above)?
No problems during upgrades. The other example (kernel) doesn't
hold
true for Fedora Core, because 0.94 contains a kernel version which is
higher than Red Hat Linux 9, 8.0 and older releases:
2.4.20-20.9 < 2.4.22-1.2061.nptl
2.4.20-20.8 < 2.4.22-1.2061.nptl
2.4.20-20.7 < 2.4.22-1.2061.nptl
Of course it works when the package version is newer, I am talking of
keeping the same package built for different releases (e.g. built form
the same specfile). Version bumping is the reason, why RH didn't
encounter that problem that often (other than the few common errata).
Even if there were a kernel upgrade for RHL<=9, I'm sure it
would see
a lower package release version than what is in Fedora Core, e.g.
2.4.22-2 in Fedora Core and 2.4.22-1.9 in Shrike Updates.
Rawhide kernel specfile even has special precautions for RH7
(sevenexcompat macro), so the current intention obviously is to
continue the common errata method, if the severn kernel turns out to
be stable enough. I pitty the kernel rpm maintainer for having to come
up with yet-another-custom-made-versioning-scheme.
Even if this should not be the case with the kernel rpm, it was only a
RH-internal example to visualize to RH devels what exists in numbers
of several hunderds in other repos. Any kludgy version numbering trick
for the next common kernel rpm release may work for that one package,
but we need a solution covering the general case.
--
Axel.Thimm(a)physik.fu-berlin.de
11:36 a.m.
New subject: Kind request: Set release version to "10"
On Wed, 2003-10-01 at 11:00, Axel Thimm wrote:
> How many packages would that be?
How many? All the ones from my repo for instance. Same for other
repos. Some of the repos have intertwining dependencies that would
also need to be updated.
Well, this is a piece of legacy that you have created for yourself. You
have opted to use an unreliable way of providing "upgradeability" for
the packages you ship that was never guaranteed to be a foolproof
solution. It is not fair to demand that this system should be continued
simply because you made a choice that might have seemed a good one in
the past, but ended up creating unnecessary legacy out of which you
cannot get out (or are unwilling).
It was never guaranteed that the versioning of releases would remain
consistent, and most packagers who have seen the jump from 8.0 to 9 have
quickly realized that making the OS version part of their release is a
very icky way of guaranteeing package upgradeability.
You've dug this hole for yourself, and I do not think it is fair to
expect us all to jump down it.
Regards,
--
Konstantin ("Icon") Riabitsev
Duke Physics Sysadmin, RHCE
3:42 a.m.
New subject: Kind request: Set release version to "10"
On Wed, Oct 01, 2003 at 12:36:34PM -0400, Konstantin Riabitsev wrote:
On Wed, 2003-10-01 at 11:00, Axel Thimm wrote:
Well, this is a piece of legacy that you have created for yourself. You
have opted to use an unreliable way of providing "upgradeability" for
the packages you ship that was never guaranteed to be a foolproof
solution. It is not fair to demand that this system should be continued
simply because you made a choice that might have seemed a good one in
the past, but ended up creating unnecessary legacy out of which you
cannot get out (or are unwilling).
You are getting me wrong here. I simply present a solution for
concurrent repositories, e.g. having the same package (sourcewise) in
RH7.3, RH8.0, RH9 and the next N releases. This is a problem that the
Fedora Legacy will face sooner or later, and it's better faced now,
where things can get fixed.
If one is interested in keeping sane upgrade paths between the
supported releases, one will find the only way to do so is to generate
rpms with VRs following this scheme:
foo-1.2.3-4<suffix1>
foo-1.2.3-4<suffix2>
foo-1.2.3-4<suffix3>
Making sure the ordering of the suffixN corresponds to the rpm upgrade
path algorithm.
The natural way to create this suffix is to use the distro versioning
number, but this has now broken. Note: not only for my repo, but for
others as well, including fedora.us!
fedora.us is saving their day with a kludge: While previously the
distro release was prepended by alphabetic characters ("rh"), they
skip it for the new releases, as anything starting with "f" is
rpm-older.
But this is already broken for Fedora Legacy, as older rpms do not
sort properly numbers and alphabetic entries (its a bug fixed only
rather recently). And even if it were, it still is a kludge to remove
the distro identification of the rpm.
It was never guaranteed that the versioning of releases would remain
consistent, and most packagers who have seen the jump from 8.0 to 9 have
quickly realized that making the OS version part of their release is a
very icky way of guaranteeing package upgradeability.
You've dug this hole for yourself, and I do not think it is fair to
expect us all to jump down it.
Please see it constructively. Maybe you are not interested in
supporting multiple distros, but other who are ("Fedora Lagacy") need
a versioning scheme they can live with.
So please provide a better working scheme.
--
Axel.Thimm(a)physik.fu-berlin.de
12:19 p.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 1 Oct 2003 18:00:51 +0300, Axel Thimm wrote:
> How many packages would that be?
How many? All the ones from my repo for instance. Same for other
repos. Some of the repos have intertwining dependencies that would
also need to be updated.
A few observations: In your repository I don't see a consistent
platform specific release tag scheme. The release tag scheme for RHL
7.3 and RHL 8.0 differs, e.g.
rpm-4.2-1_15.rh7.3.at.src.rpm
mplayer-0.90-0_16rh8.0at.src.rpm
The mplayer package for Shrike doesn't have platform tag at all.
Also note the higher package release:
mplayer-0.90-18.athlon.rpm
For Fedora Core, it seems to be %{version}-%{release}.rh9.0.94.at
style again.
Other packages don't have any such release tag at all, regardless of
whether they are in RHL already or not. Your repository contains
packages that override core components of RHL and don't allow for a
clean upgrade path, e.g.
bash-doc-2.05b-23.2.athlon.rpm
Should have been something like
bash-doc-2.05b-0.23.2.athlon.rpm
so it is guaranteed that Red Hat's bash packages always are newer
than yours.
I'm not familiar with your repository. But it looks like one of your
bigger problems is lack of a consistent and RH/Fedora compatible
package release versioning scheme.
What about repos not using the rh tag and what about repos not
willing
to give up identification of the rpm as belonging to the rh family?
When either party is "not willing to give up" something, that sets
off the alarm. ;)
What
about Fedora Legacy, should part of it be distro-tagged and some not
(like your example above)?
I haven't seen any work on guidelines for Fedora Legacy yet. But
it would sound reasonable, if 3rd party projects adapted Fedora's
.fdr release tag and vepoch.
> 2.4.20-20.9 < 2.4.22-1.2061.nptl
> 2.4.20-20.8 < 2.4.22-1.2061.nptl
> 2.4.20-20.7 < 2.4.22-1.2061.nptl
Of course it works when the package version is newer, I am talking of
keeping the same package built for different releases (e.g. built form
the same specfile).
2.4.20-20.9 = kernel for Shrike
2.4.20-20.8 = kernel for Psyche
2.4.20-20.7 = kernel for Valhalla
doesn't differ much from
2.4.20-20.rh9 = kernel for Shrike
2.4.20-20.rh8 = kernel for Psyche
2.4.20-20.rh7 = kernel for Valhalla
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/ewyM0iMVcrivHFQRAsOwAJ9v/ES9VrnWofRvT8X+0BONgsLBWgCff1d4
3wFv+gL1hmufu3mXC6FYWX0=
=IrlG
-----END PGP SIGNATURE-----
3:50 a.m.
New subject: Kind request: Set release version to "10"
On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote:
A few observations: In your repository I don't see a consistent
platform specific release tag scheme.
check the dates and the discussion on fedora.us in March/April (yes, I
was once a fedora member).
The fact is that there still is no versioning scheme one can rely
upon. The scheme we discussed with fedora.us in March/April is now
broken.
The main issue is, that RH need to come up with a consistent scheme
(not only for fedora but also including fedora legacy), or bless an
existing one.
Currently there is no schem that will work:
o either the upgrade paths are broken, e.g. rh9 -> fc1/fdr1
o or rpm bugs are triggered, e.g. rhXX -> numbers
o Red Hat policy is violated, e.g. rh9 -> rh10
I understand RH's marketing and company policy, I won't join the "free
beer" group, but I would like the policy to not spoil technical
issues.
> What about Fedora Legacy, should part of it be distro-tagged
and
> some not (like your example above)?
I haven't seen any work on guidelines for Fedora Legacy yet.
This thread _is_ about Fedora Lagacy ... ;)
--
Axel.Thimm(a)physik.fu-berlin.de
10:51 a.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 6 Oct 2003 10:50:52 +0200, Axel Thimm wrote:
On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote:
> A few observations: In your repository I don't see a consistent
> platform specific release tag scheme.
check the dates and the discussion on fedora.us in March/April (yes, I
was once a fedora member).
Been there before I joined the fedora-devel(a)fedora.us list. Going
through list archives is a time-consuming process. I prefer summaries
of ready-to-use concepts which can be commented on as a whole.
Continueing Fedora Core with Red Hat Linux specific release numbers
does not sound reasonable. It is like an implicit epoch.
You don't answer why some of your packages have no distribution specific
release tag at all and why other packages override versions found in Red
Hat Linux.
The fact is that there still is no versioning scheme one can rely
upon. The scheme we discussed with fedora.us in March/April is now
broken.
What had been the plans for RHL 9 => RHL 10? I don't remember, maybe
rh90 => rh100 or anything like that? And why is the "rh" in front of
the version? And why is it "rh90.93" instead of "9.0.93.rh"? It's
too
late to change a broken system and additionally make it play nicely
with future changes. But Fedora Core's start at "1" is the chance for
a change. I'm not that interested in learning about old broken
versions of RPM and trying to make them fit into a general concept
nevertheless.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gY9r0iMVcrivHFQRAtGSAJ9QUwPQbiYL81sPaOAhkF+UUxB5NwCeMFwP
1AqDxe01Lx+s8bROepR7zS8=
=11q1
-----END PGP SIGNATURE-----
1:47 p.m.
New subject: Kind request: Set release version to "10"
On Mon, Oct 06, 2003 at 05:51:07PM +0200, Michael Schwendt wrote:
On Mon, 6 Oct 2003 10:50:52 +0200, Axel Thimm wrote:
> On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote:
> > A few observations: In your repository I don't see a consistent
> > platform specific release tag scheme.
>
> check the dates and the discussion on fedora.us in March/April (yes, I
> was once a fedora member).
Been there before I joined the fedora-devel(a)fedora.us list. Going
through list archives is a time-consuming process. I prefer
summaries of ready-to-use concepts which can be commented on as a
whole.
You don't answer why some of your packages have no distribution specific
release tag at all and why other packages override versions found in Red
Hat Linux.
What I wanted to say is that the versioning scheme evolved, partly on
its own, partly in discussion within (the old) fedora. So when you
find inconsistency in the repo you are seeing at different layers of
history.
(I am hesitating to rebuild packages simply for re-versioning them to
avoid bandwidth consumption at end users, especially while the
versioning scheme was/is still at flux).
Continueing Fedora Core with Red Hat Linux specific release numbers
does not sound reasonable. It is like an implicit epoch.
OTOH you are right, but if the packages from the Fedora Project are to
be related to Red Hat Linux ones (e.g. you want them to be rpm-newer),
you need to come up with a compatible scheme.
Did you check Warren's proposal on doing the reverse? E.g. instead of
continuing RHL versioning into Fedora, one can back-continue Fedora
guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0.
> The fact is that there still is no versioning scheme one can
rely
> upon. The scheme we discussed with fedora.us in March/April is now
> broken.
What had been the plans for RHL 9 => RHL 10?
On fedora.us? I think the final consent was to "wait 'til it comes,
it's always different than you planned". It turns out to be more than
right. But that has to be fixed now, otherwise we will be having the
same problems with "Fedora New Core XP2004" ... ;)
I don't remember, maybe rh90 => rh100 or anything like that?
And why
is the "rh" in front of the version? And why is it "rh90.93" instead
of "9.0.93.rh"? It's too late to change a broken system and
additionally make it play nicely with future changes. But Fedora
Core's start at "1" is the chance for a change. I'm not that
interested in learning about old broken versions of RPM and trying
to make them fit into a general concept nevertheless.
That's why I changed the Subject on the main thread to contain "Fedora
Legacy". If one doesn't care about past releases, you don't see the
problem.
--
Axel.Thimm(a)physik.fu-berlin.de
2:54 p.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 6 Oct 2003 20:47:48 +0200, Axel Thimm wrote:
> > > A few observations: In your repository I don't see
a consistent
> > > platform specific release tag scheme.
> >
> > check the dates and the discussion on fedora.us in March/April (yes, I
> > was once a fedora member).
>
> Been there before I joined the fedora-devel(a)fedora.us list. Going
> through list archives is a time-consuming process. I prefer
> summaries of ready-to-use concepts which can be commented on as a
> whole.
> You don't answer why some of your packages have no distribution specific
> release tag at all and why other packages override versions found in Red
> Hat Linux.
What I wanted to say is that the versioning scheme evolved, partly on
its own, partly in discussion within (the old) fedora. So when you
find inconsistency in the repo you are seeing at different layers of
history.
I fail to see that. Here's one of the packages for Shrike, which
was touched long after the disttag discussions:
mplayer-0.90-18.athlon.rpm
http://atrpms.physik.fu-berlin.de/dist/rh9/mplayer/mplayer-0.90-18.athlon...
Or this one from July (0.9 = Shrike?):
perl-DateManip-5.42-0.9.noarch.rpm
http://atrpms.physik.fu-berlin.de/dist/rh9/perl-DateManip/perl-DateManip-...
Another one for Shrike, from the same period of time, but has a disttag:
libapt-pkg-devel-0.5.5cnc6-34.rh9.at.i386.rpm
http://atrpms.physik.fu-berlin.de/dist/rh9/apt/libapt-pkg-devel-0.5.5cnc6...
So much about consistency. There are more examples like that.
Back to the topic.
> Continueing Fedora Core with Red Hat Linux specific release
numbers
> does not sound reasonable. It is like an implicit epoch.
OTOH you are right, but if the packages from the Fedora Project are to
be related to Red Hat Linux ones (e.g. you want them to be rpm-newer),
you need to come up with a compatible scheme.
Packages in Fedora Core 1 will be newer than any packages in Red Hat
Linux. Only a few cases (e.g. comps, maybe comps-extras,
redhat-release => fedora-release) need special treatment (probably an
increased epoch).
I understand that Red Hat have never supported an upgrade path from
installations other than Red Hat Linux. The Fedora Project is a new
thing. It doubt it changes history by treating old 3rd party
repositories for Red Hat Linux as if they had been official Fedora
Extras/Alternatives/Legacy repositories before. In other words, they
are unsupported. Starting with Fedora Core 1 you may need to implement
a compatible versioning scheme, i.e. bump the release versions or
vepochs (if any) of all your old packages before you put them into
your Fedora add-ons repository. As I've pointed out before, some of
your package versions conflict with Red Hat Linux anyway (e.g. bash,
perl-DateManip, mozilla).
Did you check Warren's proposal on doing the reverse? E.g.
instead of
continuing RHL versioning into Fedora, one can back-continue Fedora
guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0.
Yes, sounds good. It's not the first time a "0." prefix is useful.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gchv0iMVcrivHFQRAslfAJ9Ot/0Jrg+idu3H9V6aAgfDaglXmgCeOTC1
Ar1JDanpiVcP03zzeURtaVc=
=TlhL
-----END PGP SIGNATURE-----
4:11 p.m.
New subject: Kind request: Set release version to "10"
On Mon, Oct 06, 2003 at 09:54:23PM +0200, Michael Schwendt wrote:
On Mon, 6 Oct 2003 20:47:48 +0200, Axel Thimm wrote:
> > > > A few observations: In your repository I don't see a
> > > > consistent platform specific release tag scheme.
> > >
> > > check the dates and the discussion on fedora.us in March/April
> > > (yes, I was once a fedora member).
> >
> > Been there before I joined the fedora-devel(a)fedora.us
> > list. Going through list archives is a time-consuming process. I
> > prefer summaries of ready-to-use concepts which can be commented
> > on as a whole.
> > You don't answer why some of your packages have no distribution
> > specific release tag at all and why other packages override
> > versions found in Red Hat Linux.
>
> What I wanted to say is that the versioning scheme evolved, partly
> on its own, partly in discussion within (the old) fedora. So when
> you find inconsistency in the repo you are seeing at different
> layers of history.
I fail to see that. Here's one of the packages for Shrike, which
was touched long after the disttag discussions:
[senseless examples skipped]
Exactly what are you trying to prove? "My repo is more consistent than
your repo"? Didn't I mention that there was evolution in the
versioning scheme, _parts of which_ were discussed with fedora.us?
(and the examples are crap also, i.e. you are ranting about mozilla's
versioning scheme, which is a verbatim copy of rawhide ...)
While the discussion with fedora.us back in March/April did create
some first specifications, others and I broke with fedora.us due to
the increased non-tolerance against other 3rd party repos.
So the maintainers of the old repos stepped back and kept and evolved
their own versioning schemes (This is a bit oversimplified, in reality
there were and are coordination efforts to keep the repos compatible).
Please don't repeat the same intolerance attitude.
So much about consistency. There are more examples like that.
Back to the topic.
> > Continueing Fedora Core with Red Hat Linux specific release numbers
> > does not sound reasonable. It is like an implicit epoch.
>
> OTOH you are right, but if the packages from the Fedora Project are to
> be related to Red Hat Linux ones (e.g. you want them to be rpm-newer),
> you need to come up with a compatible scheme.
Packages in Fedora Core 1 will be newer than any packages in Red Hat
Linux. Only a few cases (e.g. comps, maybe comps-extras,
redhat-release => fedora-release) need special treatment (probably an
increased epoch).
You trimmed (and maybe didn't read) the following from my previous
reply: "That's why I changed the Subject on the main thread to contain
"Fedora Legacy". If one doesn't care about past releases, you don't
see the problem."
This applies here also, don't let the thread loose its topic.
> Did you check Warren's proposal on doing the reverse? E.g.
instead of
> continuing RHL versioning into Fedora, one can back-continue Fedora
> guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0.
Yes, sounds good. It's not the first time a "0." prefix is useful.
I know, I introduced it into fedora.us for consistency, shortly before
I gave up ...
--
Axel.Thimm(a)physik.fu-berlin.de
4:32 p.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 6 Oct 2003 23:11:47 +0200, Axel Thimm wrote:
> [senseless examples skipped]
Ha!
Exactly what are you trying to prove? "My repo is more
consistent than
your repo"?
I don't have a repository.
Didn't I mention that there was evolution in the
versioning scheme, _parts of which_ were discussed with fedora.us?
(and the examples are crap also,
Wrong choice of words here for my taste. Aggression causes me to block
off.
i.e. you are ranting about mozilla's
versioning scheme, which is a verbatim copy of rawhide ...)
mplayer isn't.
While the discussion with fedora.us back in March/April did create
some first specifications, others and I broke with fedora.us due to
the increased non-tolerance against other 3rd party repos.
So the maintainers of the old repos stepped back and kept and evolved
their own versioning schemes (This is a bit oversimplified, in reality
there were and are coordination efforts to keep the repos compatible).
How is your current versioning scheme defined?
> Packages in Fedora Core 1 will be newer than any packages in Red
Hat
> Linux. Only a few cases (e.g. comps, maybe comps-extras,
> redhat-release => fedora-release) need special treatment (probably an
> increased epoch).
You trimmed (and maybe didn't read) the following from my previous
reply: "That's why I changed the Subject on the main thread to contain
"Fedora Legacy". If one doesn't care about past releases, you don't
see the problem."
I refused to quote it. Does Fedora Legacy cover "old releases of
Fedora Core" (quote from fedora.redhat.com) or also old release from
Red Hat Linux or also pre-Fedora 3rd party repositories?
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gd940iMVcrivHFQRAksJAJ4lLetnPevG8WsC6LVFd5jEIqv/rwCdHO1k
1D+JQIBB423hIvTjUs2L75c=
=BFeU
-----END PGP SIGNATURE-----
5:02 p.m.
New subject: Kind request: Set release version to "10"
On Monday 06 October 2003 14:32, Michael Schwendt wrote:
I refused to quote it. Does Fedora Legacy cover "old releases
of
Fedora Core" (quote from fedora.redhat.com) or also old release from
Red Hat Linux or also pre-Fedora 3rd party repositories?
Until pried otherwise from my fingers, Fedora Legacy will provide
backports for 7.3 and 9 when they respectively go EOL.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
1:28 a.m.
New subject: rpm versioning scheme (was: Kind request: Set release version to "10")
On Mon, Oct 06, 2003 at 11:32:40PM +0200, Michael Schwendt wrote:
How is your current versioning scheme defined?
Extracting kernel-modules, beta/cvs and other non-trivial examples the
versioning scheme I suggest to use (note not only for myself, and not
only for RH/FC) is:
<name>-<upstream_version>-<buildnumber>_<disttag>_<optional
repo id>
Where
o _ is a seperator, that could be "_", "." or under certain
circumstances even ""
o disttag is a combination of a distid and a distversion, e.g.
rh9, rhel3, fdr1, lsb1.3, mdk8, suse9
should be rpm-sortable within a family, e.g. rhl/fdr should be
sortable, rhel also, but possible rhl/fdr and rhel should not
compare, etc.
o repoid is an identity marker like "at", "fr", "dag",
"fdr"
They are at the least significant position to not have rpm sort on them.
repoid is optional and should not be used by vendors or first tier
packaging repos like FC. disttag
> You trimmed (and maybe didn't read) the following from my
previous
> reply: "That's why I changed the Subject on the main thread to contain
> "Fedora Legacy". If one doesn't care about past releases, you
don't
> see the problem."
I refused to quote it.
No need to comment on that, I guess ...
Does Fedora Legacy cover "old releases of Fedora Core"
(quote from
fedora.redhat.com) or also old release from Red Hat Linux or also
pre-Fedora 3rd party repositories?
--
Axel.Thimm(a)physik.fu-berlin.de
2:50 p.m.
New subject: Kind request: Set release version to "10"
On Mon, 6 Oct 2003, Axel Thimm wrote:
On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote:
> A few observations: In your repository I don't see a consistent
> platform specific release tag scheme.
check the dates and the discussion on fedora.us in March/April (yes, I
was once a fedora member).
The fact is that there still is no versioning scheme one can rely
upon. The scheme we discussed with fedora.us in March/April is now
broken.
The main issue is, that RH need to come up with a consistent scheme
(not only for fedora but also including fedora legacy), or bless an
existing one.
Currently there is no schem that will work:
o either the upgrade paths are broken, e.g. rh9 -> fc1/fdr1
o or rpm bugs are triggered, e.g. rhXX -> numbers
o Red Hat policy is violated, e.g. rh9 -> rh10
I understand RH's marketing and company policy, I won't join the "free
beer" group, but I would like the policy to not spoil technical
issues.
This has to do with marketing.
However, to stay in tune with the actual problem you're
having....
Reading the thread, it is aparent to me that many people who read
it and responded, did not completely listen to the problem which
you are describing. Numerous people completely misunderstood
what you are trying to say, or purposefully chose to not read
everything and attempt to understand it. I read your emails
fairly carefully however and believe I understand you correctly.
Without renaming or reversioning the distribution (which is just
straight plain and simple not going to happen period for any
reason short of an Act of God(TM)), there is another extremely
simple solution. Simply add an additional digit in front of the
normal modifier you use to indicate your special packages.
For example:
RHL 8.0: foo-1.2.3-3.rh80
RHL 9 : foo-1.2.3-3.rh90
FC 1 : foo-1.2.3-3.1fc1 or foo-1.2.3-3.0fc1 or
foo-1.2.3-3.1.fc1
Using this scheme, all of the packages with fc1 in their names
are considered newer by RPM than the RHL 9 or 8.0 packages above
them. No Epoch specifier is needed, no reason that the
distribution naming/versioning scheme we've chosen to go with
will break your packages. It may require some getting used to,
but the problem is trivially solveable by you for your package
repositories, and by others with their package repositories.
The reason this works, is because when rpm goes to compare 2
packages to see which is newer, it compares based on name + epoch
+ version + release. The version and release fields are compared
like this (this is fairly oversimplified):
It breaks the release field into multiple parts on field
boundaries. A field boundary occurs when the next character
transitions from alpha to numeric or numeric to alpha, or by an
optional "." or "_" delimiter character[1]. Numerals are
considered higher than alphabetic characters in a given field
number.
So taking the 3 examples above and splitting them up into fields
and comparing them, we have:
Release Field1 Field2 Field3 Field4
3.rh80 3 rh 80 N/A
3.rh90 3 rh 90 N/A
3.0fc1 3 0 fc 1
3.1fc1 3 1 fc 1
3.1.fc1 3 1 fc 1
Field 1 matches for all of them so comparison proceeds to field
2, in which case 1 is newer than 0, which is newer than "rh", so
the fc1 packages are all newer than both the rh80 and rh90
packages.
Problem solved.
Hope this helps.
TTYL
[1] There may be other delimiters I'm forgetting also, but I'm
not trying to be 100% complete here to what the rpm source code
handles, just trying to give a fairly terse example. In general,
it is best to stick to using only numeric and alphabetic
characters and ".". When in doubt, consult RPM documentation,
and source code for the complete gory details if one requires
more advanced knowledge than my terse description provides.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
2:53 p.m.
New subject: Kind request: Set release version to "10"
On Mon, 6 Oct 2003, Mike A. Harris wrote:
>I understand RH's marketing and company policy, I won't
join the "free
>beer" group, but I would like the policy to not spoil technical
>issues.
This has to do with marketing.
^
"nothing"
Oops, I left that word out.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
3:50 p.m.
New subject: Kind request: Set release version to "10"
On Mon, Oct 06, 2003 at 03:50:49PM -0400, Mike A. Harris wrote:
On Mon, 6 Oct 2003, Axel Thimm wrote:
> The fact is that there still is no versioning scheme one can rely
> upon. The scheme we discussed with fedora.us in March/April is now
> broken.
>
> The main issue is, that RH need to come up with a consistent
> scheme (not only for fedora but also including fedora legacy), or
> bless an existing one.
>
> Currently there is no schem that will work:
> o either the upgrade paths are broken, e.g. rh9 -> fc1/fdr1
> o or rpm bugs are triggered, e.g. rhXX -> numbers
> o Red Hat policy is violated, e.g. rh9 -> rh10
Reading the thread, it is aparent to me that many people who read it
and responded, did not completely listen to the problem which you
are describing. Numerous people completely misunderstood what you
are trying to say, or purposefully chose to not read everything and
attempt to understand it. I read your emails fairly carefully
however and believe I understand you correctly.
Without renaming or reversioning the distribution (which is just
straight plain and simple not going to happen period for any reason
short of an Act of God(TM)), there is another extremely simple
solution. Simply add an additional digit in front of the normal
modifier you use to indicate your special packages.
For example:
RHL 8.0: foo-1.2.3-3.rh80
RHL 9 : foo-1.2.3-3.rh90
FC 1 : foo-1.2.3-3.1fc1 or foo-1.2.3-3.0fc1 or
foo-1.2.3-3.1.fc1
This breaks with all rpm versions shipped until the beginning of this
year (including RH8.0). On rpm-list we rediscussed in January the rpm
non-symmetric bug (or letter-number toggling bug) that invalidated
ordering of segments of different types.
While there do exist backported rpm versions with this bug fixed on
rpm.org, they have not been approved to enter RH errata, yet, and a
Legacy project needs to take into account non-updated setups.
Therefore this solution, as well as dropping the letters completely
(which would have worked with the same semantics) is flawed for a
Legacy project (See also the renamed "Fedora and Fedora Legacy package
versioning schemes", where this is discussed in more detail.)
Thanks for the suggestion, though, and for taking your time to go
through it. As you noticed, only few do.
Currently I think the best way would be for RH to allow to tag the old
releases with tags like 0.7.3, 0.8.0, 0.9 to make the versioning
ordered again.
Using this scheme, all of the packages with fc1 in their names
are considered newer by RPM than the RHL 9 or 8.0 packages above
them. No Epoch specifier is needed, no reason that the
distribution naming/versioning scheme we've chosen to go with
will break your packages. It may require some getting used to,
but the problem is trivially solveable by you for your package
repositories, and by others with their package repositories.
The reason this works, is because when rpm goes to compare 2
packages to see which is newer, it compares based on name + epoch
+ version + release. The version and release fields are compared
like this (this is fairly oversimplified):
It breaks the release field into multiple parts on field
boundaries. A field boundary occurs when the next character
transitions from alpha to numeric or numeric to alpha, or by an
optional "." or "_" delimiter character[1]. Numerals are
considered higher than alphabetic characters in a given field
number.
So taking the 3 examples above and splitting them up into fields
and comparing them, we have:
Release Field1 Field2 Field3 Field4
3.rh80 3 rh 80 N/A
3.rh90 3 rh 90 N/A
3.0fc1 3 0 fc 1
3.1fc1 3 1 fc 1
3.1.fc1 3 1 fc 1
Field 1 matches for all of them so comparison proceeds to field
2, in which case 1 is newer than 0, which is newer than "rh", so
the fc1 packages are all newer than both the rh80 and rh90
packages.
Problem solved.
Hope this helps.
TTYL
[1] There may be other delimiters I'm forgetting also, but I'm
not trying to be 100% complete here to what the rpm source code
handles, just trying to give a fairly terse example. In general,
it is best to stick to using only numeric and alphabetic
characters and ".". When in doubt, consult RPM documentation,
and source code for the complete gory details if one requires
more advanced knowledge than my terse description provides.
--
Axel.Thimm(a)physik.fu-berlin.de
4:15 p.m.
New subject: Kind request: Set release version to "10"
On Mon, Oct 06, 2003 at 10:50:40PM +0200, Axel Thimm wrote:
While there do exist backported rpm versions with this bug fixed on
rpm.org, they have not been approved to enter RH errata, yet, and a
Legacy project needs to take into account non-updated setups.
Of course, whatever
the naming scheme is, one of the first Legacy
updates should be a version of rpm that doesn't have random failure modes
requiring manual intervention (i.e. the one on ftp.rpm.org or fedora),
--
Pekka Pietikainen
5:08 p.m.
New subject: Kind request: Set release version to "10"
On Tue, Oct 07, 2003 at 12:15:21AM +0300, Pekka Pietikainen wrote:
On Mon, Oct 06, 2003 at 10:50:40PM +0200, Axel Thimm wrote:
> While there do exist backported rpm versions with this bug fixed on
> rpm.org, they have not been approved to enter RH errata, yet, and a
> Legacy project needs to take into account non-updated setups.
Of course, whatever the naming scheme is, one of the first Legacy
updates should be a version of rpm that doesn't have random failure
modes requiring manual intervention (i.e. the one on ftp.rpm.org or
fedora),
Yes, most certainly, but you do see the chicken-and-egg problem?
Better to not depend on the order of the packages installed.
(OT: Unfortunately all current rpm versions still have the "random
failure modes" you refer to, even in severn2. This is probably the
reason for rpm not making it to errata. Unfortunately the bug is very
difficult to reproduce, usually happens during large updates).
--
Axel.Thimm(a)physik.fu-berlin.de
6:31 p.m.
New subject: Kind request: Set release version to "10"
On Oct 6, 2003, Axel Thimm <Axel.Thimm(a)physik.fu-berlin.de> wrote:
Yes, most certainly, but you do see the chicken-and-egg problem?
Better to not depend on the order of the packages installed.
Err... Isn't this what rpm dependencies are for?
Sure enough, you may have to run rpm -F more than once, to get the rpm
updated in the first round, and everything else later, but I can't see
other problems. Do you?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
1:44 a.m.
New subject: Kind request: Set release version to "10"
On Mon, Oct 06, 2003 at 08:31:56PM -0300, Alexandre Oliva wrote:
On Oct 6, 2003, Axel Thimm <Axel.Thimm(a)physik.fu-berlin.de>
wrote:
> Yes, most certainly, but you do see the chicken-and-egg problem?
> Better to not depend on the order of the packages installed.
Err... Isn't this what rpm dependencies are for?
Sure enough, you may have to run rpm -F more than once, to get the rpm
updated in the first round, and everything else later, but I can't see
other problems. Do you?
If rpm itself is broken and needs to be upgraded before performing any
further steps, you loose. Unless of course you make all packages
depend on rpm >= 4.1.1, but even then a buggy rpm would sort the
dependencies according to its buggy ordering algorithm and install the
wrong bits.
To summarize the problem: Some suggestions for versioning concurrent
packages for different RH/FC releases were to use the recent
letters-are-older-than-numbers idiom from rpm, e.g.
foo-1.2.3-4_rh9 < foo-1.2.3-4_1
or
foo-1.2.3-4_rh9 < foo-1.2.3-4_0fdr1
which is broken for rpm up to the one shipped with RH8.0.
I think the best suggestion was to set
"Fedora Core 0.<value>" := "Red Hat Linux <value>",
so that the resulting disttags compare letters to letters and numbers
to numbers (so the rpm non-symmetry bug is not triggered), and the
disttags sort still in chronological order, e.g.
foo-1.2.3-4_fdr0.9 < foo-1.2.3-4_fdr1
Unfortunately nobody from RH commented on this. Bill?
--
Axel.Thimm(a)physik.fu-berlin.de
4:02 p.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 6 Oct 2003 15:50:49 -0400 (EDT), Mike A. Harris wrote:
Reading the thread, it is aparent to me that many people who read
it and responded, did not completely listen to the problem which
you are describing. Numerous people completely misunderstood
what you are trying to say, or purposefully chose to not read
everything and attempt to understand it. I read your emails
fairly carefully however and believe I understand you correctly.
Interesting observation. But the solution you've come up is one that
has been covered before. It's used by fedora.us, and Axel calls it a
"kludge".
rh73 < rh80 < rh90 < 0.94 < 1
rh73 < rh80 < rh90 < 1
Whether you add something after the 0.94 (or 1), doesn't matter.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gdh90iMVcrivHFQRAvAPAJ9ljJWoDP3nfnVyWT0fmKmyVshyTACfXD5K
4s4nJsBqx0GmMfQuwGlfDrc=
=+s96
-----END PGP SIGNATURE-----
5:02 p.m.
New subject: Kind request: Set release version to "10"
On Mon, Oct 06, 2003 at 11:02:54PM +0200, Michael Schwendt wrote:
On Mon, 6 Oct 2003 15:50:49 -0400 (EDT), Mike A. Harris wrote:
> Reading the thread, it is aparent to me that many people who read
> it and responded, did not completely listen to the problem which
> you are describing. Numerous people completely misunderstood
> what you are trying to say, or purposefully chose to not read
> everything and attempt to understand it. I read your emails
> fairly carefully however and believe I understand you correctly.
Interesting observation. But the solution you've come up is one that
has been covered before. It's used by fedora.us, and Axel calls it a
"kludge".
Please Michael, stop misquoting me, it has become a bad habit of
yours. While it definitely is a kludge, you (deliberately?) skip my
main concerns about this scheme being broken by all rpm versions up to
this January, making this idiom unsuitable for "Fedora Legacy".
You know the war 1870/71 between the German states and France was
triggered because the Prussian cancler deliberately misquoted
statements of the French king towards the Prussian king?
rh73 < rh80 < rh90 < 0.94 < 1
rh73 < rh80 < rh90 < 1
Whether you add something after the 0.94 (or 1), doesn't matter.
--
Axel.Thimm(a)physik.fu-berlin.de
6:13 p.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 7 Oct 2003 00:02:20 +0200, Axel Thimm wrote:
Please Michael, stop misquoting me, it has become a bad habit of
yours. While it definitely is a kludge, you (deliberately?) skip my
main concerns about this scheme being broken by all rpm versions up to
this January, making this idiom unsuitable for "Fedora Legacy".
Rest assured, I'm out of this thread. I'm back when there are serious
attempts at developing a versioning scheme for Fedora Legacy, such as
using %{release}.0.X.Y (where 0.X.Y is e.g. 0.7.3 for Valhalla and 0.9
for Shrike), instead of trying to find a compromise for current 3rd
party repositories.
My final comments here. You're complicating matters. I'm aware that
for older versions of RPM (<= 4.1 or 4.1.1, I don't know),
rh73 < 1fdr *and* 1fdr < rh73
so that would be a problem for upgrade chanells which don't update RPM
to a better version. But where has been defined that Fedora Legacy
will carry packages with rh* disttags? Fedora Legacy has other
problems that must be considered. Obviously, packages for a Fedora
Legacy supported distribution must have a higher version than all
previous packages (E:V-R based version comparison) for that
distribution *and* all packages of older distributions. At the same
time, Fedora Legacy update packages for one distribution may not have
a higher version than stock packages of newer distributions, so the
upgrade path is not disturbed. You can only avoid that with backported
fixes, which keep the V in E:V-R below what is shipped with later
distributions, or if you break upgradability. Whether or not that may
be necessary also depends on the feasibility of backporting security
fixes in time.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gfct0iMVcrivHFQRAhZGAJ9uiKdPn/AHQOq8kfvlFkfC02dKuwCeJRUh
JMxNXPezUHhCuAr5XZcYnW0=
=Uomw
-----END PGP SIGNATURE-----
1:36 a.m.
New subject: Kind request: Set release version to "10"
On Tue, Oct 07, 2003 at 01:13:49AM +0200, Michael Schwendt wrote:
Rest assured, I'm out of this thread. I'm back when there are
serious
attempts at developing a versioning scheme for Fedora Legacy, such as
using %{release}.0.X.Y (where 0.X.Y is e.g. 0.7.3 for Valhalla and 0.9
for Shrike), instead of trying to find a compromise for current 3rd
party repositories.
You possibly haven't read the thread ...
My final comments here. You're complicating matters. I'm
aware that
for older versions of RPM (<= 4.1 or 4.1.1, I don't know),
rh73 < 1fdr *and* 1fdr < rh73
so that would be a problem for upgrade chanells which don't update RPM
to a better version. But where has been defined that Fedora Legacy
will carry packages with rh* disttags?
Where has anything concerning Fedora Legacy been defined? Isn't that
what this list members are supposed to develop?
Fedora Legacy has other problems that must be considered. Obviously,
packages for a Fedora Legacy supported distribution must have a
higher version than all previous packages (E:V-R based version
comparison) for that distribution *and* all packages of older
distributions. At the same time, Fedora Legacy update packages for
one distribution may not have a higher version than stock packages
of newer distributions, so the upgrade path is not disturbed.
You are describing the same problem.
You can only avoid that with backported fixes, which keep the V in
E:V-R below what is shipped with later distributions, or if you
break upgradability. Whether or not that may be necessary also
depends on the feasibility of backporting security fixes in time.
Not true, that's exactly when an rpm-sortable disttag in the release
tag would help. Check the rest of the thread.
--
Axel.Thimm(a)physik.fu-berlin.de
5:38 a.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 7 Oct 2003 08:36:06 +0200, Axel Thimm wrote:
> Fedora Legacy has other problems that must be considered.
Obviously,
> packages for a Fedora Legacy supported distribution must have a
> higher version than all previous packages (E:V-R based version
> comparison) for that distribution *and* all packages of older
> distributions. At the same time, Fedora Legacy update packages for
> one distribution may not have a higher version than stock packages
> of newer distributions, so the upgrade path is not disturbed.
> You can only avoid that with backported fixes, which keep the V
in
> E:V-R below what is shipped with later distributions, or if you
> break upgradability. Whether or not that may be necessary also
> depends on the feasibility of backporting security fixes in time.
Not true, that's exactly when an rpm-sortable disttag in the release
tag would help. Check the rest of the thread.
Wrong. Please consider thinking about it a bit longer before you pipe
out your usual quick replies.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gpej0iMVcrivHFQRAvxlAKCI6cCDodgZsa8krLiQsJd3zgeI0ACfdrbe
7KP/qDhOHREiQrm+tFww3Wk=
=u+O1
-----END PGP SIGNATURE-----
9:44 a.m.
New subject: Kind request: Set release version to "10"
On Monday 06 October 2003 23:36, Axel Thimm uttered:
Where has anything concerning Fedora Legacy been defined? Isn't
that
what this list members are supposed to develop?
Dude, I've replied to you a couple times about this...
http://www.fedora.us/wiki/FedoraLegacy
Legacy will have 7.3 and 9 support initially, possibly more.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (www.mondorescue.org)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
1:51 p.m.
New subject: Kind request: Set release version to "10"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 7 Oct 2003 07:44:17 -0700, Jesse Keating wrote:
On Monday 06 October 2003 23:36, Axel Thimm uttered:
> Where has anything concerning Fedora Legacy been defined? Isn't that
> what this list members are supposed to develop?
Dude, I've replied to you a couple times about this...
http://www.fedora.us/wiki/FedoraLegacy
Legacy will have 7.3 and 9 support initially, possibly more.
No secret. The list announcements and things like that are
everywhere.
It may sound like splitting hairs, but do you have official
confirmation from Red Hat or the Fedora Project committee that
"Fedora (!) Legacy" will carry updates for old release of
_Red Hat_ (!) Linux?
You try to fit RHL Legacy under the Fedora Legacy umbrella.
Fedora Legacy -- as defined at fedora.redhat.com -- and a project that
extends the Legacy concept to Red Hat Linux, are two different things,
albeit with a similar goal.
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gwsa0iMVcrivHFQRAurpAJ9/P6IfObO4g3igTi3XnWrVl63vLgCfYkcm
XCEm3zsEineCO9IDeNLsEuU=
=GsgO
-----END PGP SIGNATURE-----
1:55 p.m.
New subject: Kind request: Set release version to "10"
Michael Schwendt wrote:
It may sound like splitting hairs, but do you have official
confirmation from Red Hat or the Fedora Project committee that
"Fedora (!) Legacy" will carry updates for old release of
_Red Hat_ (!) Linux?
There is a new Fedora-legacy-list:
Fedora Legacy list list is for the discussion of the Fedora Legacy project.
This project exists to maintain security/bug backports for EOLd Red Hat
Linux and Fedora Core releases.
https://lists.dulug.duke.edu/mailman/listinfo/fedora-legacy-list
2:09 p.m.
New subject: Kind request: Set release version to "10"
On Tuesday 07 October 2003 11:51, Michael Schwendt wrote:
On Tue, 7 Oct 2003 07:44:17 -0700, Jesse Keating wrote:
> On Monday 06 October 2003 23:36, Axel Thimm uttered:
> > Where has anything concerning Fedora Legacy been defined? Isn't
> > that what this list members are supposed to develop?
>
> Dude, I've replied to you a couple times about this...
>
> http://www.fedora.us/wiki/FedoraLegacy
>
> Legacy will have 7.3 and 9 support initially, possibly more.
No secret. The list announcements and things like that are
everywhere.
It may sound like splitting hairs, but do you have official
confirmation from Red Hat or the Fedora Project committee that
"Fedora (!) Legacy" will carry updates for old release of
_Red Hat_ (!) Linux?
Fedora Legacy was coined by Warren of Fedora.US. Warren was doing
nothing with Legacy, mostly because it was there for the community to
pick up. I've picked it up, and with Warren's blessings, I'm running
with it. There isn't much to "confirm" with Red Hat, legacy is what
the community wants Legacy to be.
You try to fit RHL Legacy under the Fedora Legacy umbrella.
Fedora Legacy -- as defined at fedora.redhat.com -- and a project
that extends the Legacy concept to Red Hat Linux, are two different
things, albeit with a similar goal.
The definition of Fedora Legacy at fedora.redhat.com needs to be
updated. It was made long ago, prior to my involvement with the
project.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
8:05 a.m.
New subject: Fedora Legacy definition (was: Kind request: Set release version to "10")
On Tue, Oct 07, 2003 at 07:44:17AM -0700, Jesse Keating wrote:
On Monday 06 October 2003 23:36, Axel Thimm uttered:
> Where has anything concerning Fedora Legacy been defined? Isn't that
> what this list members are supposed to develop?
Dude, I've replied to you a couple times about this...
http://www.fedora.us/wiki/FedoraLegacy
Thanks for the pointer (are you sure you are not mistaken me with
someone else? We didn't have that much communication until now).
Legacy will have 7.3 and 9 support initially, possibly more.
That's what I also thought. Since RHL is the precursor of Fedora
Core/Project, one could define RHL <= 9 as "Fedora prenatal release"
and say that Fedora Legacy will be supporting (part of) the EOL'd
Fedora releases (including the prenatal ones ;).
--
Axel.Thimm(a)physik.fu-berlin.de
7:14 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Sep 24, 2003, Bill Nottingham <notting(a)redhat.com> wrote:
It's a new release model, hence a new release number. Fedora Core
10
doesn't make sense.
FWIW, I don't see why not. dBase II and RHEL 2.1 come to mind :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
12:21 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Thu, 2003-09-25 at 12:06, Roozbeh Pournader wrote:
On Thu, 2003-09-25 at 03:44, Alexandre Oliva wrote:
> FWIW, I don't see why not. dBase II and RHEL 2.1 come to mind :-)
Or worse than that. The first version of LaTeX was called 2.09!
I think it's a good idea, especially a nice random sounding number like
"2.09", just for the Discordian value.
Metacity did the same thing; from its README: "The first release of
Metacity was version 2.3. Metacity has no need for your petty hangups
about version numbers."
Bwahahaha...
"less" has a great scheme, too - a wholly integer based release
numbering system. The current version of less is 378. :)
- jck
--
"The bugs in Sawfish, and its greater configurability, are not
orthogonal/unrelated facts"
-- Havoc Pennington
3:02 p.m.
New subject: Retain upgrade paths (was: /etc/redhat-release?)
On Sep 25, 2003 at 12:21, Jens Knutson in a maddening rage wrote:
On Thu, 2003-09-25 at 12:06, Roozbeh Pournader wrote:
> On Thu, 2003-09-25 at 03:44, Alexandre Oliva wrote:
> > FWIW, I don't see why not. dBase II and RHEL 2.1 come to mind :-)
>
> Or worse than that. The first version of LaTeX was called 2.09!
I think it's a good idea, especially a nice random sounding number like
"2.09", just for the Discordian value.
How about 8.1. This would surely
satisfy those ppl who were
waiting for RH8.1 and got RH9.
--
Registered Linux User # 125653 (http://counter.li.org)
Switch to: http://www.speakeasy.net/refer/190653
If a guru falls in the forest with no one to hear him, was he really a
guru at all?
-- Strange de Jim, "The Metasexuals"
16:01:36 up 32 days, 3:36, 4 users, load average: 0.00, 0.00, 0.00
4:39 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths)
I am changing the subject to avoid loosing the context again. I am
also top posting, as the quoted part below is for reference only and
not a reply. I hope this longish post clarifies the problem and
stimulates more constructive discussions (no, the thread until now was
not constructive ;)
If you are a "Fedora Legacy" champion take your time please to get
through it. I hope the problem becomes more transparent that way, and
that a good solution is found before everything gets hit in stone
(e.g. November).
Thank you for your time!
The problem:
============
The aim is to have packages for Red Hat Linux and Fedora (Core) which
should be naturally (speak rpm-wise) upgradeable. For Red Hat's packages
from release to release this is ensured by
o Updated upstream versions
o Updated release tags due to different packaging or simply due to
rebuilding for the current release
o Epoch bumping where the above is not possible, e.g. downgrading a
buggy package.
When common errata were issued, either the packages were having
different upstream versions, or the errata was using an ad hoc method
for ensuring upgrade paths, usually with suffixes derived from the
distro version, like .7x, .80, .90, or .7, .8 and .9.
There was no policy on how to deal with it, as it was not really an
issue within RH.
The true trouble comes up, when you want to maintain the same package
for multiple different releases, e.g. RH7.3, RH8.0, RH9, FC/FDR 1 etc.
This is a common task in the "Fedora Legacy" subcomponent.
These packages will have the same upstream version and will (whenever
possible) be based on the same sources (same SourceN/PatchN/specfile).
This had been discussed on fedora.us half a year before. The viable
solutions that emerged were to have suffixes at the rpm release tag
that order the rpms according to the distro version, e.g.
foo-1.2.3-4_rh7.3
foo-1.2.3-4_rh8.0
foo-1.2.3-4_rh9
There are variations on this scheme, like dropping "rh" or using 73,
80, 90 instead of 7.3, 8.0 and 9.
The current decision to rewind the distro release is breaking such
schemes, and "Fedora Legacy" like repos need a solution.
Defining the problem domain for Fedora Legacy:
==============================================
a) We need a versioning scheme that ensures upgradability without
obfuscating too much the VR scheme.
b) It should be possible to use the same sources/patches/specfiles with
macro controlled differences
c) It should work with older rpm versions, e.g. don't let rpm compare
numbers with letters.
The easiest way to achieve a) and b) is to have
Release: 4_%{disttag}
in the specfile and let %{disttag} expand to values in the right
rpm-order for the given distributions.
A proposal on the fedora.us side is to allow rpm to compare "rh9"
versus "1", which under newer rpms will resolve as older, but which is
not the case for RH7.x (possibly even stock RH8.0, but I may be
mistaken). There are updated rpm rpms fixing this issue, but they are
neither available via RHN, nor can Fedora Legacy assume that those
rpms are available on the system to be upgraded.
Therefore it is far better to compare numbers only with rpm.
So we need a versioning scheme f that numerically sorts
... < f("7.3") < f("8.0") < f("9") <
f("1") < ...
Possible solutions:
===================
a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide
10"
or "RawHide 9.1". It looks compatible with RH's policy and would
allow for tags like "rh10" to complete the above scheme.
b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR.
c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" <
"number" idiom.
d) Use tags with something larger than "rh", e.g. "tfp" ("The
Fedora
Project")
X) Your suggestion here.
It is important to have Red Hat's consent on any sollution, as well as
a common versioning scheme across repositories of different
maintainers to allow for properly formulating cross-repository
dependencies and having easy identification by end users.
Optional good-to-have semantics:
================================
o Use the same versioning for Fedora.
It would be good to have a scheme applicable to both Fedora Legacy
as well as Fedora (current release). That way Fedora releases could
automatically become Fedora Legacy without rebuilding and
re-versioning.
o Use the same versioning for RawHide/Betas.
This would help building more often for RawHide. E.g. the following
scheme could be used until now:
foo-1.2.3-4_rh8.0
foo-1.2.3-4_rh8.0.93 (beta)
foo-1.2.3-4_rh8.0.94.20030325 (rawhide)
foo-1.2.3-4_rh9 (release)
On Wed, Sep 24, 2003 at 10:45:45AM +0300, Axel Thimm wrote:
On Tue, Sep 23, 2003 at 07:28:58PM -0400, Elliot Lee wrote:
> On Wed, 24 Sep 2003, Axel Thimm wrote:
>
> > What about the versioning? Will xxx-release continue to have
> > rpm-monotonic larger VRs than the previous releases?
>
> EpochVR yes, VR no.
>
> The beta will have redhat-release-0.94-1 (epoch 1).
That is ugly in multiple ways. Leaving all other reasons for not
using epochs aside, this will break all upgrade paths from embedded
disttags like 7.3, 8.0 or 9. The logical conduction would be to have
these repos also bump up epochs to ensure rpm upgradability or invent
their own versioning.
Any way it will be creating confusion and disorder. ;)
Could a better mechanism be created before the 25th that enables
disttags to be carried on? Please use no epoch/release, and make the
version be (rpm-)bigger than "9". Also keep redhat-release as a proper
package carrying that version information.
Background:
===========
Up to now RH was not often in the need to release multiple versions of
the same package for different RH releases. Even if the package did
not change its release tag was bumbed (rebuilt for xxx).
Errata were either based on different upstream sources, so no upgrade
clashes could come up, while in the very rare cases, where exactly the
same package was rebuilt for different RH release the package
maintainer had to invent a scheme that worked in that timeframe
(e.g. the kernel errata releases for RH 7.3/8.0/9).
3rd party repos have been using the idiom of keeping the same upstream
release current in multiple RH releases more often. The only portable
way up to now to do so was to inspect the rpm-version value of
redhat-release. Tags were created like
foo-fooversion-foorelease.rh8.0.i386.rpm
etc., ensuring sane upgrade paths for users of the 3rd party
repo. Here are some google pointers:
http://www.google.com/search?q=rpm+%22--qf%22+version+redhat-release
My plea is therefore to
o keep redhat-release as a package of its own, so that
`rpm -q --qf "%{VERSION}" redhat-release' still works.
o Make the version of this package rpm-monotonic without using epoch
(or even release tags), e.g. use a version rpm-larger than "9".
o Put redhat-release into rawhide carrying the anaconda version ...
The alternative is to break the upgrade path mechanism of several
repos or single package sites, please don't.
--
Axel.Thimm(a)physik.fu-berlin.de
5:04 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths)
Axel Thimm writes:
c) Drop upgradability from rpm < 4.1 and use kludgy
"rhnumber" <
"number" idiom.
A little observation I haven't seen so far. (But I can have missed it
in the long thread, sorry if so.):
It will matter that "rhnumber" < "number" only for systems from
FC1
and on. And those systems come rpm > 4.2. Systems with rpm < 4.1
should never have to see the packages without rh.
So it ought to work out right in practice. It's still kludgy, though.
6:53 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths)
On Mon, Oct 06, 2003 at 12:04:44PM +0200, Göran Uddeborg wrote:
Axel Thimm writes:
> c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" <
> "number" idiom.
A little observation I haven't seen so far. (But I can have missed it
in the long thread, sorry if so.):
It will matter that "rhnumber" < "number" only for systems from
FC1
and on. And those systems come rpm > 4.2. Systems with rpm < 4.1
should never have to see the packages without rh.
Well, not for "Fedora Legacy", which is about supporting systems
before FC1 (and later FC1 also etc.).
So it ought to work out right in practice. It's still kludgy,
though.
--
Axel.Thimm(a)physik.fu-berlin.de
5:13 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths)
On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote:
A proposal on the fedora.us side is to allow rpm to compare
"rh9"
versus "1", which under newer rpms will resolve as older, but which is
not the case for RH7.x (possibly even stock RH8.0, but I may be
mistaken).
Small addendum: I just looked it up for another communication on
fedora.us list. This bug was fixed 9 months ago in rpm 4.2-0.55:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50977#c20
So that means that even RH8.0 is affected. I assume the 4.1.1 backport
available from rpm.org does contain the bug-fix, but I know nothing
about 4.0.5.
There are updated rpm rpms fixing this issue, but they are neither
available via RHN, nor can Fedora Legacy assume that those rpms are
available on the system to be upgraded.
[...]
c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" <
"number" idiom.
This should then probably be "rpm < 4.1.1".
Anyway, the presence of this bug prohibits mixing numerical and
alphabetical segments in rpm comparision for any system running an rpm
from before 2003, unless rpm is upgraded to a version without this bug
before any other upgrading operation.
Therefore IMHO mixing numerical and alphabetical segments in
comparisons should be avoided for legacy considerations.
--
Axel.Thimm(a)physik.fu-berlin.de
5:48 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths)
Le lun 06/10/2003 à 12:13, Axel Thimm a écrit :
On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote:
Anyway, the presence of this bug prohibits mixing numerical and
alphabetical segments in rpm comparision for any system running an rpm
from before 2003, unless rpm is upgraded to a version without this bug
before any other upgrading operation.
Therefore IMHO mixing numerical and alphabetical segments in
comparisons should be avoided for legacy considerations.
At one point you should consider if providing a fixed rpm version for
all affected systems and have all updates depend on this rpm version is
not easier than trying to come with the perfect backwards-compatible
macro.
Cheers,
--
Nicolas Mailhot
6:08 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes
Nicolas Mailhot wrote:
Le lun 06/10/2003 à 12:13, Axel Thimm a écrit :
>On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote:
>Anyway, the presence of this bug prohibits mixing numerical and
>alphabetical segments in rpm comparision for any system running an rpm
>from before 2003, unless rpm is upgraded to a version without this bug
>before any other upgrading operation.
>
>Therefore IMHO mixing numerical and alphabetical segments in
>comparisons should be avoided for legacy considerations.
At one point you should consider if providing a fixed rpm version for
all affected systems and have all updates depend on this rpm version is
not easier than trying to come with the perfect backwards-compatible
macro.
+1
Exactly. And given rpm-4.1 from RH8 as an example, why would anyone
WANT to not upgrade it... =)
Warren
6:51 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes
On Mon, Oct 06, 2003 at 01:08:26AM -1000, Warren Togami wrote:
Nicolas Mailhot wrote:
>Le lun 06/10/2003 à 12:13, Axel Thimm a écrit :
>
>>On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote:
>
>
>>Anyway, the presence of this bug prohibits mixing numerical and
>>alphabetical segments in rpm comparision for any system running an rpm
>>from before 2003, unless rpm is upgraded to a version without this bug
>>before any other upgrading operation.
>>
>>Therefore IMHO mixing numerical and alphabetical segments in
>>comparisons should be avoided for legacy considerations.
>
>
>At one point you should consider if providing a fixed rpm version for
>all affected systems and have all updates depend on this rpm version is
>not easier than trying to come with the perfect backwards-compatible
>macro.
>
+1
Exactly. And given rpm-4.1 from RH8 as an example, why would anyone
WANT to not upgrade it... =)
Then why isn't is offered on RHN?
--
Axel.Thimm(a)physik.fu-berlin.de
6:06 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes
Thank you for your well written proposal.
Axel Thimm wrote:
Defining the problem domain for Fedora Legacy:
==============================================
a) We need a versioning scheme that ensures upgradability without
obfuscating too much the VR scheme.
b) It should be possible to use the same sources/patches/specfiles with
macro controlled differences
c) It should work with older rpm versions, e.g. don't let rpm compare
numbers with letters.
a + b are perfectly valid, but I see no reason to continue to support
the ugly behavior of c, and here's why:
1) jbj has long indicated that he wishes all distributions to use the
same upgraded version of rpm in order to simplify maintenance.
2) Fedora Legacy is the time to FORCE everyone to upgrade RPM if they
wish to continue to use the repository. This means that we will be able
to avoid a lot of unpredictable behavior (#1) in older versions of rpm,
making Legacy distributions easier to support in the long term.
3) RH 8.0 Psyche rpm *needs* to be upgraded anyway because the default
rpm is too broken to use.
(Read the bottom of this message for a summary of my %{release} naming
proposal.)
The easiest way to achieve a) and b) is to have
Release: 4_%{disttag}
in the specfile and let %{disttag} expand to values in the right
rpm-order for the given distributions.
A proposal on the fedora.us side is to allow rpm to compare "rh9"
versus "1", which under newer rpms will resolve as older, but which is
not the case for RH7.x (possibly even stock RH8.0, but I may be
mistaken). There are updated rpm rpms fixing this issue, but they are
neither available via RHN, nor can Fedora Legacy assume that those
rpms are available on the system to be upgraded.
Therefore it is far better to compare numbers only with rpm.
So we need a versioning scheme f that numerically sorts
... < f("7.3") < f("8.0") < f("9") <
f("1") < ...
Possible solutions:
===================
a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide
10"
or "RawHide 9.1". It looks compatible with RH's policy and would
allow for tags like "rh10" to complete the above scheme.
-1
Too confusing to have different numbers and names in different places.
b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR.
-999
We should always maintain upgradability between distributions, and
Fedora will strengthen this and prevent problems by stricter packaging
standards than those enforced by RH internally in the past. There is
currently absolutely no reason to break upgradability.
c) Drop upgradability from rpm < 4.1 and use kludgy
"rhnumber" <
"number" idiom.
-1
d) Use tags with something larger than "rh", e.g. "tfp" ("The
Fedora
Project")
-500
The whole reason why we had those dist tags was because fedora.us (or
freshrpms, or dag, or axel, etc.) were not official repositories. Now
Fedora is official, so I believe we can drop this ugliness that makes
the package filename unnecessarily longer.
X) Your suggestion here.
It is important to have Red Hat's consent on any sollution, as well as
a common versioning scheme across repositories of different
maintainers to allow for properly formulating cross-repository
dependencies and having easy identification by end users.
Optional good-to-have semantics:
================================
o Use the same versioning for Fedora.
It would be good to have a scheme applicable to both Fedora Legacy
as well as Fedora (current release). That way Fedora releases could
automatically become Fedora Legacy without rebuilding and
re-versioning.
+1
o Use the same versioning for RawHide/Betas.
This would help building more often for RawHide. E.g. the following
scheme could be used until now:
foo-1.2.3-4_rh8.0
foo-1.2.3-4_rh8.0.93 (beta)
foo-1.2.3-4_rh8.0.94.20030325 (rawhide)
foo-1.2.3-4_rh9 (release)
+1
I dislike your specific examples that contain "rh", but the numbers I
fully agree.
Warren's Release Naming Proposal (draft 1)
==========================================
All distributions in Fedora Legacy must upgrade to the latest version of
rpm for that distribution.
%{release} name structure
-------------------------
X.%{non-numeric version}.%{distrel}
X
RPM package release number, always increments with every update, even a
rebuild.
%{non-numeric version}
Non-numeric characters at the end of upstream's %{version}. Since
%{version} must (almost) never contain non-numeric characters in order
to avoid the Epoch treadmill (like mozilla package), the non-numeric
portion can optionally be contained within the %{release} tag after the
release number.
Examples:
mozilla-1.5-5.rc2
foobar-2.0-7.cvs20031005
%{distrel} Upgrade Path from fedora.us
--------------------------------------
0.fdr.X.rh80 -> 0.fdr.X.rh90 -> 0.fdr.X.0.94 -> 0.94 -> 1
fedora.us currently has an even longer "0.fdr.X" prepended before the
suggested fedora.redhat.com scheme. Thus absolutely anything containing
numbers in the second glob will "win" against "fdr".
Examples:
foobar-1.5-6.rc3_1.9.2 (Fedora Core 1.92 beta)
foobar-1.5-6.rc3_1 (Fedora Core 1)
foobar-1.5-6.rc3_0.9.4 (Fedora Core 0.94)
foobar-1.5-6.rc3_0.8 (RHL 8.0 Psyche)
foobar-1.5-6.rc3_0.7.3 (RHL 7.3)
Note that I used "_" instead of "." in this particular example.
Either
of them would work. The former would be a clearer seperator between the
%{distrel} and the rest of the tag, while the latter is slightly easier
to type. I personally don't care which one is used. Opinions?
Warren
7:17 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes
On Mon, Oct 06, 2003 at 01:06:30AM -1000, Warren Togami wrote:
Axel Thimm wrote:
>Defining the problem domain for Fedora Legacy:
>==============================================
>
>a) We need a versioning scheme that ensures upgradability without
> obfuscating too much the VR scheme.
>b) It should be possible to use the same sources/patches/specfiles with
> macro controlled differences
>c) It should work with older rpm versions, e.g. don't let rpm compare
> numbers with letters.
>
a + b are perfectly valid, but I see no reason to continue to support
the ugly behavior of c, and here's why:
1) jbj has long indicated that he wishes all distributions to use the
same upgraded version of rpm in order to simplify maintenance.
2) Fedora Legacy is the time to FORCE everyone to upgrade RPM if they
wish to continue to use the repository. This means that we will be able
to avoid a lot of unpredictable behavior (#1) in older versions of rpm,
making Legacy distributions easier to support in the long term.
3) RH 8.0 Psyche rpm *needs* to be upgraded anyway because the default
rpm is too broken to use.
I partly agree, but imagine the first time initiation of a existing
RH7.3 cluster of machines. The admin would have to manually update the
rpm rpms and then point his up2date/yum/apt config to a "Fedora
Legacy" repo.
Red Hat has been very conservative to replace the rpms in RH8.0 (and
RH7.3) and even when a QA rpm release is pushed into RHN, "Fedora
Legacy" should work with non-updated systems, too (just like you have
to build apt/yum/up2date against a non-updated system).
>a) Call _internally_ the next release ("Fedora [Core]
1") "RawHide 10"
> or "RawHide 9.1". It looks compatible with RH's policy and would
> allow for tags like "rh10" to complete the above scheme.
-1
Too confusing to have different numbers and names in different places.
Yes, but even Windows users could cope with different maket and
technical versions, and technically it is the cleanest solution.
>b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR.
-999
I agree, but this is still a possible solution ;)
>c) Drop upgradability from rpm < 4.1 and use kludgy
"rhnumber" <
> "number" idiom.
-1
>
>d) Use tags with something larger than "rh", e.g. "tfp"
("The Fedora
> Project")
-500
The whole reason why we had those dist tags was because fedora.us (or
freshrpms, or dag, or axel, etc.) were not official repositories. Now
Fedora is official, so I believe we can drop this ugliness that makes
the package filename unnecessarily longer.
You are talking about the .fdr. tag, e.g. the repo tag. Drop that by
all means. I am referring to the disttag like rh9 etc.
> X) Your suggestion here.
>
>It is important to have Red Hat's consent on any sollution, as well as
>a common versioning scheme across repositories of different
>maintainers to allow for properly formulating cross-repository
>dependencies and having easy identification by end users.
>
>Optional good-to-have semantics:
>================================
>o Use the same versioning for Fedora.
> [...]
+1
>o Use the same versioning for RawHide/Betas.
> [...]
+1
I dislike your specific examples that contain "rh", but the numbers I
fully agree.
Note that redhat/fedora packages are also distributed on larger
mirrors containing Mandrake, suse etc. rpm. A lot of people get the
wrong rpm. An identification string there is nice-to-have (but nothing
more, the true problem lies not here and this should not distract).
Examples:
foobar-1.5-6.rc3_1.9.2 (Fedora Core 1.92 beta)
foobar-1.5-6.rc3_1 (Fedora Core 1)
foobar-1.5-6.rc3_0.9.4 (Fedora Core 0.94)
foobar-1.5-6.rc3_0.8 (RHL 8.0 Psyche)
foobar-1.5-6.rc3_0.7.3 (RHL 7.3)
Note that I used "_" instead of "." in this particular example.
Either
of them would work. The former would be a clearer seperator between the
%{distrel} and the rest of the tag, while the latter is slightly easier
to type. I personally don't care which one is used. Opinions?
I am already using _ for that purpose, and will even ask Jeff in the
future to give _ a higher seperating pririty than . (but that's
another issue, don't want to get off-topic).
I see another suggestion in your examples (which I didn't clearly read
through the description):
e) Prepend "0." to previous RH releases, e.g.
0.7.3 < 0.8.0 < 0.9 < 0.9.0.93 < ... < 1.0
I personally like that. so how about conaming "RHL X" to "Fedora Core
0.X" resulting to tags like foo-1.2.3-4_fdr0.7.3 (non-numeric upstream
versions, kernel modules and other special cases aside)?
--
Axel.Thimm(a)physik.fu-berlin.de
9:48 a.m.
New subject: Fedora and Fedora Legacy package versioning schemes
On Monday 06 October 2003 05:17, Axel Thimm uttered:
I personally like that. so how about conaming "RHL X" to
"Fedora Core
0.X" resulting to tags like foo-1.2.3-4_fdr0.7.3 (non-numeric upstream
versions, kernel modules and other special cases aside)?
I think the "fdr" part should be removed all together. Packages are kept in
different directory trees for the relative distro. If some poor user pulls a
rpm from a FedoraCore/ directory and expects it to work on Mandrake, thats
his problem, not ours.
I've always disliked the text tags (rhl9, fdr, fr2, etc..) and I feel that
they are indicitive of 3'rd party rpms. Fedora.us and Fedora Legacy are less
3'rd party and thus shouldn't suffer the headache of text tags.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (www.mondorescue.org)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
1:51 p.m.
New subject: Fedora and Fedora Legacy package versioning schemes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 6 Oct 2003 14:17:14 +0200, Axel Thimm wrote:
> > d) Use tags with something larger than "rh", e.g.
"tfp" ("The Fedora
> > Project")
>
> -500
> The whole reason why we had those dist tags was because fedora.us (or
> freshrpms, or dag, or axel, etc.) were not official repositories. Now
> Fedora is official, so I believe we can drop this ugliness that makes
> the package filename unnecessarily longer.
You are talking about the .fdr. tag, e.g. the repo tag. Drop that by
all means. I am referring to the disttag like rh9 etc.
Fedora.us was separate from Red Hat [Linux]. And fedora.us could have
offered packages for Mandrake Linux (.mdk), for instance. Hence the
distribution tag to emphasize the target platform.
The .fdr tag and the 0. release prefix should be adapted by 3rd party
repositories. (http://fedora.redhat.com/participate/terminology.html)
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/gbmw0iMVcrivHFQRAvcBAJ9syQ4dXmxt4LBRdqNBQj+6EWFIiQCfS3H7
M/oJNgFCaMEv0vXWIa2bq/E=
=YHa1
-----END PGP SIGNATURE-----
2:45 p.m.
New subject: Fedora and Fedora Legacy package versioning schemes
Le lun 06/10/2003 à 20:51, Michael Schwendt a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 6 Oct 2003 14:17:14 +0200, Axel Thimm wrote:
> > > d) Use tags with something larger than "rh", e.g.
"tfp" ("The Fedora
> > > Project")
> >
> > -500
> > The whole reason why we had those dist tags was because fedora.us (or
> > freshrpms, or dag, or axel, etc.) were not official repositories. Now
> > Fedora is official, so I believe we can drop this ugliness that makes
> > the package filename unnecessarily longer.
>
> You are talking about the .fdr. tag, e.g. the repo tag. Drop that by
> all means. I am referring to the disttag like rh9 etc.
Fedora.us was separate from Red Hat [Linux]. And fedora.us could have
offered packages for Mandrake Linux (.mdk), for instance. Hence the
distribution tag to emphasize the target platform.
Well, we've been happily providing mandrake and redhat java packages
without any distributions tags for months at jpackage.
People just put their distro-specific repository entries into apt and
never ever see other packages. Same for ximian (of course for jpackage
it helps 90% of the packages are noarch and have no overlap with
whatever is already in the distributions, but anyway we've never needed
any special flags to differenciate distro-specific packages).
And BTW I'm deeply sceptical about Fedora getting mandrake acceptance
short term. urpmi means the mdk communities had an head start, and we're
only now catching up with apt/yum. RedHat is pretty late in the
community game.
Cheers,
--
Nicolas Mailhot
5:54 p.m.
Michael Schwendt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is known yet what will happen to /etc/redhat-release?
In case the 2nd Severn Beta will be the first Fedora Core "test"
release, will /etc/redhat-release be gone already and reappear as
/etc/fedora-release?
Sort of
$ cat /etc/fedora-release
Fedora Core release 0.90.94 (Severn)
or similar? Or will there be a different transition?
Any known details would be interesting in order to prepare some
src.rpms in Fedora.us's Severn repository for Cambridge.
- --
When the new beta comes out, is the rhn_applet gonna let us know?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/cMik0iMVcrivHFQRAj6GAJoC2iiPUGkpBomgLnYtBJ5UCy3G7ACffma2
TrM3jChftfTtzwwTUVClpRM=
=ljtj
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
7498
days inactive
7518
days old
70 comments
23 participants
participants (23)
-
Alexandre Oliva -
Axel Thimm -
Bill Nottingham -
Elliot Lee -
Florian La Roche -
Göran Uddeborg -
Jason Luka -
Jens Knutson -
Jesse Keating -
Konstantin Ryabitsev -
Michael Schwendt -
Mike A. Harris -
ne... -
Nicolas Mailhot -
Nicolas Mailhot
-
Pekka Pietikäinen -
Peter Bowen -
Roozbeh Pournader -
Sean Middleditch -
Thomas Bendler -
Warren Togami -
Wil Cooley -
Xose Vazquez Perez