[plug] re opening linuxconf

[skribe]

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.

> 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.

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
-- 
Public key information available at:
http://www.amber.com.au/~skribe/publickey.html
Key fingerprint = A855 9CA3 953B 5195 C518  12F2 0E05 DCCD 5A88 E8A4 

Men are those creatures with two legs and eight hands.
		-- Jayne Mansfield