On Tue, Jun 13, 2006 at 03:17:28PM +1000, [EMAIL PROTECTED] wrote:
On 13 Jun, Matthew Palmer wrote:
I wouldn't say that it can't fail, but I can't think of too many upgrades of
Debian or Ubuntu boxes where it's completely done itself in, and I've done
some pretty crazy stuff over the years -- custom packages, mixing releases,
that sort of thing. On the other hand, I have seen some people who've
managed to make a complete dog's breakfast of their systems such that the
system won't upgrade, but I think that's more PEBKAC than PEID.
That seems to be the consensus. (No one has volunteered any serious
problems in upgrading a Debian system.) Though Billy Kwong noted that
it depended a bit on how many packages you have installed:
Not "how many", just "which ones". Sometimes you'll get cruft that'll hang
around, but if it's likely to cause serious problems the system is fairly
good at figuring it out (through the definition of some pretty serious
chunks of package metadata -- what depends, conflicts, etc with what).
That's a worry, actually. I seem to have a knack for finding good,
usable software that then gets abandoned. Because I like the usability
of the older package I don't want to remove it; but it stands in the way
of newer versions needed by other software.
I suspect this problem will continue to exist as long as we continue to
use shared objects instead of static linking.
Pretty much. You can't completely get around it with static linking, though
-- programs evolve over time, and as their interfaces change, anything that
needs that program needs to evolve too (I'm thinking programs that call some
other command line program to do some work, for example).
Consensus on RH seems to be that the upgrade problem strongly exists
for that. So I think I'll try Ubuntu - last time I tried to install
a plain Debian (nine months ago), I gave up after I realised I still had
another 200 hundred questions to answer about configuring the kernel,
and if I changed my mind about an earlier question I'd suffer.
Hahahaha. The newer installer is a lot better there, but for
minimal-grilling installation, Ubuntu is pretty darn good.
BTW, what approach do these upgradable distros take to installing new
kernels? I.e. keeping the right modules available and matched to the
kernel that's booting, and allowing older kernels to stay in the boot
config?
On Ubuntu, at least, the default install will install a dummy package called
(for example) linux-686, which depends on the current version of the kernel
suitable for use by a 686-class machine (currently something like
linux-2.6.15-37-686). Each new release of Ubuntu will install a newer
version of linux-686, which will, in turn, install a new "real" kernel
package.
I don't think there's any automatic cleanup of old kernel packages in an
Ubuntu system, but it's not a major hassle as the new ones get booted by
default, and if you need the old one because (for example) the new one locks
up, you'll really love having a bunch of old kernels to flip through.
Does Ubuntu allow the use of Lilo instead of Grub?
Yes, but it's not the default option (and so you won't see it in the normal
install process). You can certainly install it afterwards though if you
want to, and I'm fairly certain that new kernels will get automatically
detected and lilo rerun. Don't quote me on that, though -- it's been a
while since I ran lilo (seriously, get used to grub, and you'll learn to
really love it).
- Matt
