[plug] re opening linuxconf

[Beau Kuiper]

On Sun, 6 May 2001, skribe wrote:

> On Sun,  6 May 2001 14:21, Beau Kuiper wrote:
>
> > I imagine a packaging system which attempts to upgrade libc5 to libc6 will
> > fall into the same hole, or have to upgrade every package on the system to
> > link and use libc6, essentually a new distribution.
>
> Once again from memory, the RH distribution I ended up moving to allowed for
> both versions of the library to co-exist.  I think it was RH4.  I did a base
> install and then upgraded the libraries to lib6.  I ended up with both libc5
> and libc6 on my system.  The old stuff was linked to libc5 and the new stuff
> to libc6.  As I said this is all from memory and it's fairly hazy.

There may be some subtle problems with such a setup, like I described
above.

>
> > upgrading libc on a unix system (unless it is a binary compatible fix for
> > security issues) is something you shouldn't try to do.
>
> I think I was upgrading to kernel2.x. due to hardware compatibility issues.
> Slackware wasn't exactly rushing their updates and so to upgrade required me
> either to wait until Patrick pulled his finger out, or to do-it-yerself. I'm
> not even certain that slackware's pkgtool allowed a full version upgrade
> then.  All I can remember about it is that to (un)install anything required a
> reboot into single user mode.

Huh, kernel 2.2 works fine with libc5. I have done it myself. But that is
beside the point now :-)

>
> I tried to upgrade the libraries and hosed them.  Docs were a little lacking
> in those days.  I spent several months without being able to do much until I
> found someone that had written a script that did the upgrade for you.  It
> worked great but I knew there had to be an easier way.  I deliberated about
> whether to choose RH or Debian and eventually went with RH because of the
> range of software already available for it.
>
> I respect your reasons for avoiding package systems.  There are times when
> they've caused caused me problems (like moving the sendmail.cf and not
> telling me or removing the old one and the new one allowed relays).  And I'd
> really like a better way to upgrade versions on RH-based systems.  Something
> interactive.  I'd rather spend 2-3 hours doing an interactive upgrade, than
> 2-3 days trying to work out the problems caused by an automated upgrade.
> Upgrading from a stock Mandrake 7.1 to 7.2 left the original kde1 packages
> installed which conflicted with the new kde2 packages.  And mandrake have
> admitted on Mandrake forum that upgrading 7.2 to 8 is not advised because of
> the possibility of package conflicts.  But in the end, that's nothing to the
> problems I've encountered relying solely on tarballs. I'm lazy.  I don't want
> to have to pore over the makefile to see where the program is going to dump
> its load.  And I generally avoid compiling stuff where I can because
> invariably it either requires extra libraries I don't have or something isn't
> configured properly and so I have to sift through the code to find out what
> is wrong.  That's not something I want to do just to install a new widget.  I
> just want to type rpm -ivh widget.rpm.  Or more often these days to click on
> a button that says install. And more importantly, to uninstall the widget I
> just have to type rpm -e widget.  Some tarballs have uninstall scripts but
> not all.
>
> I'm glad you like using tarballs but for me it's just too hard.
>
> skribe
>

I agree that using tarballs isn't often the easiest thing around, and that
most people would rather let the computer take care of it :-)

Beau Kuiper
kuiperba at cs.curtin.edu.au