Subject: Re: Upgrading Champion Server release 1.2 to Champion Server release 2.1?
From: nathan r. hruby (nhruby@arches.uga.edu)
Date: Mon Feb 25 2002 - 15:27:54 MST
On Mon, 25 Feb 2002, Dan Burcaw wrote:
>
>
> 1.2.1 -> 2.x *should* be possible with yup technology. I haven't had time
> to hash out a HOWOT :(
>
Previous thought on this list has been that it's not yupable. My
experiments have been similar, it's a ckicken or the egg solution:
newer yup's -require-> rpm4 -require-> db3 -require-> updated glibc
Rebuilding the packages from the 2.0 series for 1.2.1 still doesn't work,
becasue it requires that glibc jump.
Since most things in 1.2.1 require the version of glibc installed on
1.2.1, you're stuck doing the dist upgrade with the currently installed
yup, which I belive doesn't want to do that. Please correct me if I am
wrong :)
> > Also, if the 2.1 updates work for 2.0 why aren't they being pushed out in
> > yup-land? That's not a rebuild at all but a simple copy to the correct
> > ftp dir and a yup-arch commmand, no? Even with rebuilding 2.1 updates for
> > 2.0, all that would need to happen is that the 2.1 src.rpm's are --rebuilt
> > on 2.0 for proper glibc happyness. This could be automated and proabbly
> > easily moved into the build process that TSS has now.
>
> Yes. We know have our build process chrooted so it would allow our
> build machines to have chroots associated with each rev of YDL.
> In the past we'd have to keep old revisions on a machine here or there
> and as machines are limited, this hasn't always been easily doable.
>
So, is that something you're going to start doing in the near future?
> >
> > True, rebuilding the updates is very very complicated, espically with
> > 1.2.1 in view of rpm4, db3, etc... Major pain I know. But that said, it
> > shouldn't too hard to mark a product EOL, keep a copy running on a machine
> > and just patch the source tarballs from that release and --rebuild those.
> > This would be harder to automate into the build process I would think as
> > most patches against newer sources would not patch well, but still.. even
> > for 6 - 12 months to allow squiggle time would be (imho) a nice thing.
>
> I agree and I think we should be able to do this in the future, especially
> as I shake out a few more features of our chroot build environment.
>
Cool.
> That said, there will absolutely be an update path from 2.x -> 3.x.
> Due to the nature of upgrades we can't suggest this option as
> clean installs are always better, but it will be a functional part
> of the distribution with 3.0 (although I'm getting a little head of
> myself... ;-)
>
Agreed. Upgrades can be messy but if they are a needed thing then well
they're needed.
-- ...... nathan hruby - nhruby@arches.uga.edu computer support specialist department of drama and theatre http://www.drama.uga.edu/ ......
This archive was generated by hypermail 2a24 : Mon Feb 25 2002 - 15:45:28 MST