Another topic I find interesting especially for servers is the yum upgrade path;
If you download the fedora-release package for Fedora N+1, along with it's dependency fedora-release-notes of course, and install it, you should find a large number of updates available to the system.
Needless to say, either a "yum update" or a "yum upgrade", even when just applied to specific packages only, should update the system to whatever packages Fedora N+1 has to offer. Long story short, you should end up with a Fedora N+1 system. The key word being "should".
Although this is not a very feasible way to upgrade servers (as it may interrupt services running on the system because of the replacement of binaries and libraries), I'm not stabbing at this for the concern of stability -as obviously when from your point of view you need stability what the he^H^H are you doing installing Fedora on the server.
Sometimes, like with Fedora Core 1 to Fedora Core 2 upgrades, you will find yourself behind to console to accompany the change to using udev; there's not much we can do about that.
Sometimes though, and this is where I get back to the actual point of this message, like with the upgrade from Fedora 8 to Fedora 9, as it turns out there's no upgrade path for essential packages like openssl; Here's why:
openssl on a Fedora 8 system has a newer NEVRA then the available package in Fedora 9+Updates. This causes yum and rpm to disregard the Fedora 9 openssl package as an update although in Fedora 8, openssl is the package that offers the libssl.so.6 library a lot of other packages depend upon. In Fedora 9, this library is called libssl.so.7. Needless to say, if the Fedora 9 version of the openssl packages does not end up on the to-be-upgraded system as an update or upgrade, a lot of packages depending on libssl.so.6 won't be upgraded, and the packages depending on libssl.so.7 won't be upgraded either.
Now, to put this into perspective, my servers at home run Fedora, both as a testing ground, because I need recent stuff to do stuff with and because I find the well-known derivatives a little boring.
Is the Server SIG interested in pursuing a package maintainer guideline that requires Fedora N+X should _always_ have newer NEVRA then Fedora N?
Kind regards,
Jeroen van Meeuwen -kanarip
Another topic I find interesting especially for servers is the yum upgrade path;
If you download the fedora-release package for Fedora N+1, along with it's dependency fedora-release-notes of course, and install it, you should find a large number of updates available to the system.
Needless to say, either a "yum update" or a "yum upgrade", even when just applied to specific packages only, should update the system to whatever packages Fedora N+1 has to offer. Long story short, you should end up with a Fedora N+1 system. The key word being "should".
Although this is not a very feasible way to upgrade servers (as it may interrupt services running on the system because of the replacement of binaries and libraries), I'm not stabbing at this for the concern of stability -as obviously when from your point of view you need stability what the he^H^H are you doing installing Fedora on the server.
Sometimes, like with Fedora Core 1 to Fedora Core 2 upgrades, you will find yourself behind to console to accompany the change to using udev; there's not much we can do about that.
Sometimes though, and this is where I get back to the actual point of this message, like with the upgrade from Fedora 8 to Fedora 9, as it turns out there's no upgrade path for essential packages like openssl; Here's why:
openssl on a Fedora 8 system has a newer NEVRA then the available package in Fedora 9+Updates. This causes yum and rpm to disregard the Fedora 9 openssl package as an update although in Fedora 8, openssl is the package that offers the libssl.so.6 library a lot of other packages depend upon. In Fedora 9, this library is called libssl.so.7. Needless to say, if the Fedora 9 version of the openssl packages does not end up on the to-be-upgraded system as an update or upgrade, a lot of packages depending on libssl.so.6 won't be upgraded, and the packages depending on libssl.so.7 won't be upgraded either.
Now, to put this into perspective, my servers at home run Fedora, both as a testing ground, because I need recent stuff to do stuff with and because I find the well-known derivatives a little boring.
Is the Server SIG interested in pursuing a package maintainer guideline that requires Fedora N+X should _always_ have newer NEVRA then Fedora N?
As a LiveUpgradeSIG member http://fedoraproject.org/wiki/SIGs/LiveUpgrade and someone who also runs runs home servers on Fedora, I give this an extremely emphatic +500.
Kind regards,
Jeroen van Meeuwen -kanarip _______________________________________________ fedora-server-list mailing list fedora-server-list@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
Jon Ciesla wrote:
Is the Server SIG interested in pursuing a package maintainer guideline that requires Fedora N+X should _always_ have newer NEVRA then Fedora N?
As a LiveUpgradeSIG member http://fedoraproject.org/wiki/SIGs/LiveUpgrade and someone who also runs runs home servers on Fedora, I give this an extremely emphatic +500.
So I suppose we can draft up a packager guideline that makes sense, and propose it to FPSCo/FESCo.
/me adds that to the list of tasks
One other thing, would it be feasible to write a little python script that runs against a local mirror and checks for these things? Did we not use to have something like that already?
-Jeroen
Jon Ciesla wrote:
Is the Server SIG interested in pursuing a package maintainer guideline that requires Fedora N+X should _always_ have newer NEVRA then Fedora N?
As a LiveUpgradeSIG member http://fedoraproject.org/wiki/SIGs/LiveUpgrade and someone who also runs runs home servers on Fedora, I give this an extremely emphatic +500.
So I suppose we can draft up a packager guideline that makes sense, and propose it to FPSCo/FESCo.
/me adds that to the list of tasks
One other thing, would it be feasible to write a little python script that runs against a local mirror and checks for these things? Did we not use to have something like that already?
We did, but I'm not sure who was running it. It was wonderful.
-Jeroen
Jon Ciesla píše v Po 15. 12. 2008 v 08:26 -0600:
Another topic I find interesting especially for servers is the yum upgrade path;
If you download the fedora-release package for Fedora N+1, along with it's dependency fedora-release-notes of course, and install it, you should find a large number of updates available to the system.
Needless to say, either a "yum update" or a "yum upgrade", even when just applied to specific packages only, should update the system to whatever packages Fedora N+1 has to offer. Long story short, you should end up with a Fedora N+1 system. The key word being "should".
Although this is not a very feasible way to upgrade servers (as it may interrupt services running on the system because of the replacement of binaries and libraries), I'm not stabbing at this for the concern of stability -as obviously when from your point of view you need stability what the he^H^H are you doing installing Fedora on the server.
Sometimes, like with Fedora Core 1 to Fedora Core 2 upgrades, you will find yourself behind to console to accompany the change to using udev; there's not much we can do about that.
Sometimes though, and this is where I get back to the actual point of this message, like with the upgrade from Fedora 8 to Fedora 9, as it turns out there's no upgrade path for essential packages like openssl; Here's why:
openssl on a Fedora 8 system has a newer NEVRA then the available package in Fedora 9+Updates. This causes yum and rpm to disregard the Fedora 9 openssl package as an update although in Fedora 8, openssl is the package that offers the libssl.so.6 library a lot of other packages depend upon. In Fedora 9, this library is called libssl.so.7. Needless to say, if the Fedora 9 version of the openssl packages does not end up on the to-be-upgraded system as an update or upgrade, a lot of packages depending on libssl.so.6 won't be upgraded, and the packages depending on libssl.so.7 won't be upgraded either.
Now, to put this into perspective, my servers at home run Fedora, both as a testing ground, because I need recent stuff to do stuff with and because I find the well-known derivatives a little boring.
Is the Server SIG interested in pursuing a package maintainer guideline that requires Fedora N+X should _always_ have newer NEVRA then Fedora N?
As a LiveUpgradeSIG member http://fedoraproject.org/wiki/SIGs/LiveUpgrade and someone who also runs runs home servers on Fedora, I give this an extremely emphatic +500.
This is a general Fedora issue affecting all groups. There used to be some "Broken upgrade paths" reports, IIRC, but can't recall when I had last seen them.
Dan
Jeroen van Meeuwen píše v Po 15. 12. 2008 v 15:52 +0100:
Dan Horák wrote:
This is a general Fedora issue affecting all groups. There used to be some "Broken upgrade paths" reports, IIRC, but can't recall when I had last seen them.
My gut feeling says they were lost during the core/extras merge...
now there is https://fedorahosted.org/rel-eng/browser/scripts/check-upgrade-paths.py
Dan
Jeroen van Meeuwen wrote:
Is the Server SIG interested in pursuing a package maintainer guideline that requires Fedora N+X should _always_ have newer NEVRA then Fedora N?
I'd agree that Fedora N+x should always have NEVRA >= Fedora N
I'd agree that (Fedora + updates) N+x should always have NEVRA >= Fedora + updates) N
I'd not agree that Fedora N+x should always have NEVRA >= Fedora + updates) N, and I think there would be a lot of resistance to enforcing that.
Paul.
server@lists.fedoraproject.org
-
Dan Horák -
Jeroen van Meeuwen -
Jon Ciesla -
Paul Howarth