[4477] in testers
Re: Linux 8.3.31 -> 8.4.4 layered upgrade
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jun 20 10:45:18 2000
Message-Id: <200006201444.KAA03545@small-gods.mit.edu>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: testers@MIT.EDU
In-Reply-To: Your message of "Tue, 20 Jun 2000 02:31:28 EDT."
<200006200631.CAA00963@No-Whammies.mit.edu>
Date: Tue, 20 Jun 2000 10:44:57 -0400
From: Greg Hudson <ghudson@MIT.EDU>
> vim-minimal is on the 8.4.4 release list in the control subdir.
Huh? No it's not.
> That file, BTW, has some stray numbers like " 1" and " 5" that you
> have to remove before feeding the list to rpm. I don't know if
> these are intentional.
Those are epoch numbers, and are intentional. The rpmupdate program
knows how to deal with them. You're not intended to feed the list-*
files to rpm on a layered system; if you have a layered system, you're
not supposed to be relying on our help to maintain the base Red Hat
installation (although you're welcome to use the RPM files we've stuck
in AFS, of course).
The layered-* files (which only contain the athena RPMs) don't have
this problem, since none of the athena RPMs have epochs. Of course,
we haven't been making layered-* files for the 8.4 series yet, but
they're just the result of "grep '^athena' list-foo".
> I also had to manually remove athena-tex athena-xdm because these
> packages have apparently been split and/or renamed, and there were
> lots of install conflicts.
Yeah, that's a bit tricky. (rpmupdate can deal with simultaneous
removals and additions.) We might need to amend our instructions to
suggest that people use rpmupdate on the layered-* lists for full
release upgrades if they're installing all of the Athena RPMs.
> /etc/athena/rc.conf is empty of variables...that seemed odd.
That's a problem. I believe it can happen if you had a very early set
of 8.3 RPMs.
> athena-voldump gave "rmdir of / failed: No such file or directory"
No clue here.
> athena-krb5 gave:
> Not updating conf.getty to point at krb5. Current value:
> LOGIN=/usr/athena/etc/login.krb5
This is harmless but annoying, and happens to everyone (it amounts to
"not updating conf.getty to point at krb5 because it already points
there"). I looked at it briefly and wasn't sure what the easiest way
was to get rid of it.
> Users who upgrade in this fashion should be advised to edit
> /etc/lilo.conf (and run lilo) before rebooting, to make sure it
> points to the current kernel.
Again, the layered model assumes that you are responsible for
maintaining the base Red Hat install. We are somewhat loathe to start
documenting stuff which isn't related to the Athena RPMs.
