Re: /lib symlinks problem?

On Mon, 1 Sep 2003, M. Warner Losh wrote:

> In message: <20030901015535.Y3776_at_znfgre.qbhto.arg>
>             Doug Barton <DougB_at_freebsd.org> writes:
> : On Mon, 1 Sep 2003, M. Warner Losh wrote:
> :
> : > My tool is initially just a 'delete these files' tool, but now that I
> : > think about it, it wouldn't be hard to say also 'create these
> : > symlinks'.  The hard part here is generating the 'obsolete' lists.
> :
> : I posted one approach to this today... touch a file right before you
> : start installworld, then consider anything not newer than that file a
> : candidate for disposal. There is currently something weird going on in
> : /usr/lib though... a lot of the files don't have newer dates, I haven't
> : tracked down why yet.
>
> No.  That's not what I'm talking about.  That approach is crap,
> because installworld doesn't touch all files.

Please tell us how you really feel! :) I have never said that my
suggestion was a complete solution to the problem. But it does get you
pretty far down the road for any given instance of installworld, without
needing to maintain complicated databases of what files have been
installed by the system.

I would think that using my suggestion in directories where we _do_
touch every file (like *[s]bin) would make your task easier, but since I
haven't seen your WIP yet, I'll reserve further comment till I do.

> : Also, I highly recommend NOT deleting the files, but moving them
> : somewhere. This makes it much easier to recover if you delete something
> : you shouldn't have.
>
> I don't care the method of removal.  I care more about the list.  If
> you want to mv them them instead of rm, it isn't a big deal to change
> that detail.

Ok, consider this a request to do that then. As suggestions, I currently
use two different methods to deal with this. In the after_installworld
script I posted, I create an 0ld directory in the same directory as the
files I want to back up. I use zero as the first character so it always
sorts at the top for easy identification. For mergemaster's -P option, I
create /var/tmp/mergemaster/preserved-files-yymmdd-hhmmss, where the
time is the time that the run of mergemaster started. Both approaches
have merit. For binaries and libs my thinking was that leaving them on
the same file system will make it possible to recover if one of the
things you happened to mv turned out to be important during mount
time/boot time.

> The mv /usr/foo -> /usr/foo.old is too dangerous, and I think it is
> the wrong way to go.

Well, I started doing it for /usr/include and /usr/share/man personally
because nothing from either directory is needed for installworld, and I
know for a fact that I'm rigorous about not putting any foreign stuff in
there. I'm certainly not married to the idea of doing it that way.

As I've been saying all along, the stuff I've been posting is little
more than Proof of Concept work atm. My goal has been to defeat the
inertia surrounded by "we cannot make this work!" by demonstrating one
method that does work, albeit imperfectly. The fact that you're moving
farther down this road is music to my ears. :)

Doug

-- 

    This .signature sanitized for your protection