Date: Thu, 12 Jun 2003 13:16:40 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Garance A Drosihn <drosih@rpi.edu>, Doug Barton <DougB@FreeBSD.org> Cc: arch@freebsd.org Subject: Re: removing stale files Message-ID: <20030612034640.GM57496@wantadilla.lemis.com> In-Reply-To: <20030611144115.E26376@12-234-22-23.pyvrag.nggov.pbz> <p05210614bb0d30155a2e@[128.113.24.47]> <p05210613bb0d2187f0dd@[128.113.24.47]> References: <20030611075750.GB57496@wantadilla.lemis.com> <20030611.093203.26943899.imp@bsdimp.com> <p05210613bb0d2187f0dd@[128.113.24.47]> <20030611190615.GA15695@dhcp01.pn.xcllnt.net> <p05210614bb0d30155a2e@[128.113.24.47]> <20030610124747.A7560@phantom.cris.net> <20030610024524.D23396@znfgre.qbhto.arg> <20030611075750.GB57496@wantadilla.lemis.com> <20030611.093203.26943899.imp@bsdimp.com> <p05210613bb0d2187f0dd@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
--/t6ASE28jIy1gGy9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 11 June 2003 at 14:36:49 -0400, Garance A Drosihn wrote: > At 9:32 AM -0600 6/11/03, M. Warner Losh wrote: >> In message: <20030611075750.GB57496@wantadilla.lemis.com> >> "Greg 'groggy' Lehey" <grog@freebsd.org> writes: >>> I think we should work towards a policy where we say "these >>> directories belong to the system. Don't install your own >>> things there until you know exactly what you are doing.". >>> That would greatly simplify the job of keeping things up >>> to date. > > I have also tried to implement a few of my own ideas, and > often ended up with something that was just too fragile for > me to trust. I mean, I knew I could get it to work for *my* > system and what *I* need (after some trial-and-error), but > I would never trust it enough to recommend that "everyone" > could just blindly run it. Exactly. This is the biggest problem we have. We want to have the warm fuzzies that it will work, preferably without intervention. On Wednesday, 11 June 2003 at 16:08:39 -0400, Garance A Drosihn wrote: > At 12:06 PM -0700 6/11/03, Marcel Moolenaar wrote: >> As for the argument that removing a library, binary or header >> may break some tools, scripts or sources that depend on it: >> If that happens, we failed to maintain backward compatibility. >> The bug is not in the removal of a stale file, but in the >> fact that the file has become stale. Keeping stale files >> around only hides the bug. > > That isn't quite what I'm concerned about. I just want to > be sure that we are *only* removing files when we *know* > what they are. There are several ways to achieve this. One is the somewhat fascist method I suggest above: for a specific list of directories (/bin, /sbin, /usr/bin, /usr/sbin, /usr/include and so on), we say "this belongs to the system. Don't put anything there". That way we really can remove old stuff without worrying about it. On Wednesday, 11 June 2003 at 14:49:02 -0700, Doug Barton wrote: > On Wed, 11 Jun 2003, Marcel Moolenaar wrote: > >> On Wed, Jun 11, 2003 at 04:08:39PM -0400, Garance A Drosihn wrote: >>> At 12:06 PM -0700 6/11/03, Marcel Moolenaar wrote: >>>> As for the argument that removing a library, binary or header >>>> may break some tools, scripts or sources that depend on it: >>>> If that happens, we failed to maintain backward compatibility. >>>> The bug is not in the removal of a stale file, but in the >>>> fact that the file has become stale. Keeping stale files >>>> around only hides the bug. >>> >>> That isn't quite what I'm concerned about. I just want to >>> be sure that we are *only* removing files when we *know* >>> what they are. >> >> We always know, because we own them. > > The problem is, we don't know if the user has modified them or > not. This is one of the reasons mergemaster exists for /etc stuff. The problem with mergemaster in its current form is that it leaves too much work to the user. I've just installed a 5.0 CD-ROM, upgraded to latest -CURRENT, and run mergemaster -ia. It left me with 268 files to merge by hand. A big part of the problem is exactly the fact that mergemaster can't know whether it can change files like /etc/defaults/rc.conf. That's because we have no official policy about it. Sure, at the top it says: # This is rc.conf - a file full of useful variables that you can set # to change the default startup behavior of your system. You should # not edit this file! But it's not official: "should". /etc is a special case, of course. We can't just blow everything away. But we can extend the concept of /etc/defaults/rc.conf reading /etc/rc.conf to other files as well. With others (/etc/inetd.conf) we can't. But if we were to move all user-modifiable script-like files to a separate subdirectory, we could not only make the upgrade less painful, but also come closer to a read-only root file system. > I would say that at bare minimum, IF the community consensus is to > do this in installworld, that there be a knob to turn it off. Absolutely. > I'd still rather see this functionality in a seperate utility > though. I'd *really* like to get back to the good old days of upgrading with a single "make world". If it's a different target (make autoupgrade, for example), that's fine by me. Greg -- See complete headers for address and phone numbers --/t6ASE28jIy1gGy9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+5/egIubykFB6QiMRArHXAJ9YjlwoRu/DyAr9r2M3v8z+8KwF3ACfUiiR vWzL9E3o9j1siKcSHHEjy/U= =dTy6 -----END PGP SIGNATURE----- --/t6ASE28jIy1gGy9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030612034640.GM57496>