-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
1) A script that will create a package specific for that given system 2) Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On 4/17/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
- A script that will create a package specific for that given system
- Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
Are you looking for something otehr than anaconda for small memory or something? I do not see live updates working for the faint of heart from 4.4 -> 5.0 .
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Apr 17, 2007 at 12:55:24PM -0600, Stephen John Smoogen wrote:
On 4/17/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
- A script that will create a package specific for that given
system 2) Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
Are you looking for something otehr than anaconda for small memory or something? I do not see live updates working for the faint of heart from 4.4 -> 5.0 .
Nah, mostly remote systems, hosted on datacenters or somewhere else.
So far, the main problem I've encontered is really xorg. Go figure.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa spake the following on 4/17/2007 12:00 PM:
On Tue, Apr 17, 2007 at 12:55:24PM -0600, Stephen John Smoogen wrote:
On 4/17/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
- A script that will create a package specific for that given
system 2) Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
Are you looking for something otehr than anaconda for small memory or something? I do not see live updates working for the faint of heart from 4.4 -> 5.0 .
Nah, mostly remote systems, hosted on datacenters or somewhere else.
So far, the main problem I've encontered is really xorg. Go figure.
[]s
You can do remote anaconda installs using vnc. I have done it once or twice. Now if you could do remote ssh based text installs, that would really rock!
Yup, I know, just letting you know so I don't forget.
B
Scott Silva wrote:
Rodrigo Barbosa spake the following on 4/17/2007 12:00 PM:
On Tue, Apr 17, 2007 at 12:55:24PM -0600, Stephen John Smoogen wrote:
On 4/17/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
- A script that will create a package specific for that given
system 2) Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
Are you looking for something otehr than anaconda for small memory or something? I do not see live updates working for the faint of heart from 4.4 -> 5.0 .
Nah, mostly remote systems, hosted on datacenters or somewhere else.
So far, the main problem I've encontered is really xorg. Go figure.
[]s
You can do remote anaconda installs using vnc. I have done it once or twice. Now if you could do remote ssh based text installs, that would really rock!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Apr 17, 2007 at 12:16:50PM -0700, Scott Silva wrote:
Rodrigo Barbosa spake the following on 4/17/2007 12:00 PM:
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
- A script that will create a package specific for that given
system 2) Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
Are you looking for something otehr than anaconda for small memory or something? I do not see live updates working for the faint of heart from 4.4 -> 5.0 .
Nah, mostly remote systems, hosted on datacenters or somewhere else.
So far, the main problem I've encontered is really xorg. Go figure.
You can do remote anaconda installs using vnc. I have done it once or twice. Now if you could do remote ssh based text installs, that would really rock!
Humm, that really doesn't cover my needs, since it would need direct interaction with the hardware (or something nasty to give you an anaconda boot).
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa spake the following on 4/17/2007 12:31 PM:
On Tue, Apr 17, 2007 at 12:16:50PM -0700, Scott Silva wrote:
Rodrigo Barbosa spake the following on 4/17/2007 12:00 PM:
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
- A script that will create a package specific for that given
system 2) Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
Are you looking for something otehr than anaconda for small memory or something? I do not see live updates working for the faint of heart from 4.4 -> 5.0 .
Nah, mostly remote systems, hosted on datacenters or somewhere else.
So far, the main problem I've encontered is really xorg. Go figure.
You can do remote anaconda installs using vnc. I have done it once or twice. Now if you could do remote ssh based text installs, that would really rock!
Humm, that really doesn't cover my needs, since it would need direct interaction with the hardware (or something nasty to give you an anaconda boot).
[]s
Not really. You can scp the pxe kernels onto the machine and add a boot stanza into grub to run them with all the necessary commands and addresses on the command line. You just need a way to make sure you fix the grub boot back to the new kernel after the install. I just found this howto to make a remote install Cd, but with a little adjusting, you could get this working totally remote, with a http install from anywhere in the world. http://lists.centos.org/pipermail/centos-docs/2006-September/000015.html
On 4/17/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Apr 17, 2007 at 12:55:24PM -0600, Stephen John Smoogen wrote:
On 4/17/07, Rodrigo Barbosa rodrigob@darkover.org wrote:
I'm working on a formula to enable a clean upgrade from 4.4 to 5.0. Unfortunately, not only we have a big glibc upgrade on our way, we also have some nasty package fragmentation. The best exemple is xorg-x11-libs, which was separated in several (10+, perhaps) packages.
So far, I think the best plan is to create meta packages to solve this dependency hell. Lets call it meta-4.4to5.0-upgrade.noarch.rpm. This package should provide and requires the needed components.
Unfortunatelly, this will probably change from system to system, which can become very nasty. In that case, we have two ways to procede:
- A script that will create a package specific for that given
system 2) Several meta packages
I'm kind of leaning toward the second option, with a super meta package that will require them all (in case someone want to make things simples at the cost of installing extra packages).
Comments ? Suggestions ?
Are you looking for something otehr than anaconda for small memory or something? I do not see live updates working for the faint of heart from 4.4 -> 5.0 .
Nah, mostly remote systems, hosted on datacenters or somewhere else.
So far, the main problem I've encontered is really xorg. Go figure.
If xorg is the major stumbling block on a remote server why not simply do:
yum remove xorg*
before doing your upgrade?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alastair, there is no need to send a copy of your reply directly to me. Just to the list will do.
On Tue, Apr 17, 2007 at 05:56:50PM -0400, Alastair Neil wrote:
Nah, mostly remote systems, hosted on datacenters or somewhere else. So far, the main problem I've encontered is really xorg. Go figure.If xorg is the major stumbling block on a remote server why not simply do: yum remove xorg* before doing your upgrade?
Several things depend on xorg, including some stuff on the base install. I really wish it was as simple as that.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Hi,
Rodrigo Barbosa wrote:
- A script that will create a package specific for that given system
- Several meta packages
A couple of scripts and process' have been proposed, including one that Bill did on the wiki just the other day, perhaps you could start there and maybe combine the efforts ? Bill has been putting in a fair bit of effort into the upgrade process and is quite receptive to most ideas.
There was another, longer and more involved route, posted to the docs list - not sure if its on the wiki as yet.
Comments ? Suggestions ?
just one comment - I'd really like to see a functional process that can move most peoples platform from 4.4 to 5.0 :)
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Apr 18, 2007 at 01:28:38AM +0100, Karanbir Singh wrote:
Hi,
Rodrigo Barbosa wrote:
- A script that will create a package specific for that given
system 2) Several meta packages
A couple of scripts and process' have been proposed, including one that Bill did on the wiki just the other day, perhaps you could start there and maybe combine the efforts ? Bill has been putting in a fair bit of effort into the upgrade process and is quite receptive to most ideas.
There was another, longer and more involved route, posted to the docs list - not sure if its on the wiki as yet.
Most processes I've seen so far on the lists here, although funcional, are very far from that I'm aiming at.
I want something clean, and 100% based on RPM (the script I'm proposing would only create a rpm package). In this case, it is better to start from scratch.
I'm not saying ther other method aren't good. They just are not what I want, and it is very easy for me to get on the wrong track is I base my efforts on theirs, as good as they are.
Comments ? Suggestions ?
just one comment - I'd really like to see a functional process that can move most peoples platform from 4.4 to 5.0 :)
As usual, time avaliability is my main problem. Thankfuly, at this point, I'm mostly running scripts and parsing results (gotta love sed).
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Karanbir Singh wrote:
There was another, longer and more involved route, posted to the docs list - not sure if its on the wiki as yet.
No, not yet. Completely forgot about that.
Ralph
-
Alastair Neil -
Bruce Holzrichter -
Karanbir Singh -
Ralph Angenendt -
Rodrigo Barbosa -
Scott Silva -
Stephen John Smoogen