[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cleaning up after update to 3.6
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: Cleaning up after update to 3.6
- From: "openbsd64_(_at_)_rbentley_(_dot_)_com" <openbsd64_(_at_)_rbentley_(_dot_)_com>
- Date: Tue, 08 Feb 2005 12:55:29 +0000
> You just answered your own question (and sortof rephrased Nick's answer) - there's no way for a library to tell, which programs are still linked against it. To keep track of things like that, you need some database and record these dependencies in it.
Yes, I know this. [gritted teeth]
> The ports infrastructure does that, and the beefed up version in -current does it even better - but it still can't save you from getting a screwed up system if you delete a library manually. Nick is right, the only way to get around this in a safe way is to do a backup of the relevant configuration and user files (/etc, /home and some stuff in /var) and reinstall.
Agreed. I never said otherwise. I was only suggesting that it might be an idea to provide a list of obsolete libraries for a STANDARD installation. I'm not suggesting this for -current / snapshots or for supporting third party software - just the STANDARD stuff off the CD.
> There are ways to keep a system tidy. For example, instead of installing a program that doesn't exist in the ports tree directly from its respective tarball, you can write your own port in /usr/ports/mystuff/<category>/<port>....
I can easily work out what my third party software does and does not need. It's the base code (off the CD) that is the issue - there is no information readily available that describes dependencies on libraries for core code / standard packages. I can easily work out that my third party code no longer needs library whatever, version x, but I can't confidently remove it because I don't know if the BASE code still needs it.
> ...and enjoy all the nice tidying up capabilities of the ports infrastructure even on currently unsupported software.
But making a port will not clean up old libraries, will it ? No it won't.
> Writing a port can be easy (in some cases less so, but most of the time it is), and it's a useful skill to have. This way, you get your program to link against a newer libc usually by simply doing "make uninstall install clean".
I have no problem linking third party code against newer libraries, or installing it, or cleaning up the old version. Making a port will not change this or clean up old libraries and Perl junk.
> My very personal opinion, however, is that those things really are peanuts and not worth wasting much time on.
I've spent more time writing this post than finding the old libraries.
> You see, this really depends on how you manage your box - giving lengthy instructions in some FAQ entry on how to clean up those things (as long as prerequesites A to Z are met) hardly makes any sense.
Agreed. I wasn't suggesting a lengthy description. Just something along the lines of "For a standard update from version X to version Y, the following libraries are now redundant : ....". Obviously, this won't take account of any third party software, but I wouldn't expect it to; it's your own look-out if you are using third party code to make sure it still works.
This is already done to some extent - the 3.5 -> 3.6 FAQ already mentions that some devices need removing, and that the old version of cksum and sum can be deleted. All I'm suggesting is that it could be extended to include libraries and huge lumps of Perl stuff. if it's worth doing for something tiny like cksum, then why is it not worth doing for MBytes of old libraries and Perl crud ?
> What if one of your users has something compiled in his ~/bin, would you just break it for him?
NO ! You are completely (and I suspect, deliberately) missing the point of my suggestion.
> I consider it bad practice to give instructions on how to break things; people can do that without help very well, if they insist.
Ever wish you never started something ?...... Please, forget it. I'll sort it out myself (I had anyway), and I'll stop caring about making potentially useful suggestions that might benefit others who might not even be aware of the issue. And if you don't think it's useful, then fine - I don't care any more.
Rich.
Visit your host, monkey.org