Re: RFC: automated way of removing old base system files (only for a recent 6-current!)

Zitat von "M. Warner Losh" <imp_at_bsdimp.com>:

> In message: <20041024124805.378e6bc3_at_Magellan.Leidinger.net>
>             Alexander Leidinger <Alexander_at_Leidinger.net> writes:
> : But mtree doesn't has an option to ask the user if he really wants to
> : delete those files (at least it's not very obvious if you fast-read the
> : man-page). Even if they are old base system files, I don't want to just
> : remove them without explicit permission. Better safe than sorry. But
> : maybe I'm paranoid (at least for files and directories, but I strongly
> : discourage the automated removal of old libs).
>
> Either you want things clean or you don't :-).  Old libraries almost

I want things clean, without getting hurt. I see a lot of foot shooting
potential here. The way I have it ATM allows me to decide if I want to
remove a lib or not. When I know what I use on a system, I can think a
little bit about it and decide to not remove a library if I want to make
sure nothing breaks. It may be the case you forgot about a pice of
software you didn't installed from the ports. And seing a particular
library may remind you of such a program (maybe because you wrote it
yourself).

> certainly should always be removed as well, because should always be
> using the compat* port versions of these libraries.  When a library
> goes stale, it moves to a different directory.

And my effort is to allow for an easy transition. You may have not
updated all ports (in the case you don't want to install the compat
libs). With my approach an admin can make the system "not completely
clean".

> : If there's consensus that we should use mtree to remove the files and
> : directories I will switch to mtree (so far you're the only one who
> : responded to this, so it would be nice of someone else would tell us his
> : prefered color too), but you have to write a lot more to convince me to
> : do the same for the libraries.
>
> The old, stale libraries may well be obsolete from a compat point of
> view as well as a security hole point of view.  The libraries are the
> FIRST thing that I tend to purge from my systems.  It has been my
> experience that stale libraries cause more problems than just about
> any other binary in the tree.

Yes, I agree. That's the reason I want such a feature in the base system.
But I want to be able to control it. A global "leave or remove" decission
isn't enough, I want a more fine grained control like my actual approach.
You may not know in advance which libraries get removed, the actual way
you will see if e.g. an outdated openssl lib gets removed and you're able
to say "Shit! I forgot to update apache+mod_ssl! I better abort and update
mod_ssl first."

> We can easily have two mtree files if that's a real problem.
>
> The reason I suggested mtree, is that NetBSD has been using
> mtree.obsolete for years to automatically delete files.  No one over
> there has complained about that feature in all the time I've been
> reading NetBSD's mailing lists.

Just because nobody complains it doesn't mean we can't come up with
something better.

> Hmmm, looking at NetBSD's sources right now shows just lists of
> obsolete files, segregated by installation set and platform.  At the
> very least it shouldn't be MAKEFILE variables.

What's bad about using makefile variables? The makefile way we can have
one file dedicated to one task (removing obsolete files), but can decide
to split it up into several stages (files, dirs, libs), and we even are
able to remove "disabled" files (e.g. remove files depending on the
setting on the NO_FOO variables in make.conf). The mtree way we need a
lot more files, is this really needed?

I see a benefit in having only one file. Think about virtual servers
(jails) which you may be able to buy. Unfortunately not every company
which may offer such a service has good admins. So in case of an update
of all the vservers on a machine they may not have removed old files.
With the actual approach you (as a client who purchased one of those
virtual servers) just copy this one file and remove them on your own.
With a multiple file aproach you have to know a lot more of the internal
workings of a "make delete-old" (and you don't want to install the entire
source just to remove some files). And if you just want to use a clean
system, this isn't userfriendly.

What's the benefit of using mtree instead of the actual approach?

Bye,
Alexander.

-- 
http://www.Leidinger.net/     Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org/        netchild _at_ FreeBSD.org  : PGP ID = 72077137
"When I was crossing the border into Canada, they asked if I had any
firearms with me.  I said, `Well, what do you need?'"
		-- Steven Wright