Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Nov 2002 08:15:09 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Mark Murray <mark@grondar.org>, Kris Kennaway <kris@obsecurity.org>
Cc:        current@FreeBSD.ORG
Subject:   Re: perl5.6.1 wrapper
Message-ID:  <p05200f12b9f6a49a4ba2@[128.113.24.47]>
In-Reply-To: <200211082313.gA8NDgJC004268@grimreaper.grondar.org>
References:  <20021108215352.GA26821@rot13.obsecurity.org> <200211082313.gA8NDgJC004268@grimreaper.grondar.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 11:13 PM +0000 11/8/02, Mark Murray wrote:
>  > > I mean *all* the cruft -- old modules and config files,
>  > > deprecated binaries and man pages, even old shlibs if it's safe.
>  >
>  > I agree with you, and I was giving an example that a lesser
>  > form of this is already required during the upgrade.
>  >
>  > It would be VERY useful if someone could develop a script to
>  > do this (e.g. install various versions of 4.x and do an upgrade,
>  > then collect a complete list of all the stale files).

Sometime soon I hope to get a new machine for my freebsd testing,
one which would be considerably faster than the one I have.  It
should also soon be true that I won't be as swamped at my "day job",
so I would have some time to try to do something like this.

I would only be doing this on i386 though, and I don't know if there
would be significant differences for a similar list on alpha's.

>#=========================================
>#!/bin/sh
>
>installdirs=	/bin /sbin /usr/bin /usr/sbin /usr/libdata 
>/usr/libexec /usr/include /usr/share /usr/lib
>
>for dir in ${installdirs} ; do
>	find ${dir} -type f -ctime +1 -delete
>	find ${dir} -type d -empty -delete
>	find ${dir} -type l -delete
>done
>
># 4.x -> 5.x only:
># rm -rf /kernel* /modules*
>
>cd /usr/src && make installworld
>#=========================================
>
>The second "make installworld" is to repopulate your lib/compat/ dirs,
>rebuild the hierarchy and to catch files (groff support IIRC) that
>this erroneously deletes.
>
>I do this pretty often.

With 5.0-release, we will start to have people who are upgrading
"somewhat production-ish" systems from 4.x-stable.  I think it
would be rather hostile of us to blindly remove files based only
on the last time they were changed.  The users could have a number
of files of their own in these paths, files that will do absolutely
no harm if left, and which could cause problems if they are blindly
removed.  Since this will be "5.0-stable", we will not be able to
use the favorite excuse that "hey, this branch is documented as the
cutting edge, so if you were screwed by it then it's your own fault".

I would rather have some explicit list of filenames where we have
good reason to delete them, and then adapt the above script to at
least tell the user about the remaining files.  Perhaps even delete
them, but only *after* saving a copy away in some tar file.  Just
to do something which is a bit friendlier to all the people who
will be seeing 5.0 for the first time.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05200f12b9f6a49a4ba2>