Re: /lib symlinks problem?

In message: <20030901122624.A6074_at_znfgre.qbhto.arg>
            Doug Barton <DougB_at_freebsd.org> writes:
: 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! :)

Maybe I was a little strong in what I said.

: 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.

We need to keep some database.  Either incrementally as we go, so that
we know all that belongs in certain directories (which is risky
because some third party software installs stuff into them), or we
need to keep track of what we've shipped in the past so we can remove
it when it is obsolete.

Your solution kills the ability to keep old libraries around in
/usr/lib/compat, for example, without freshly installing them every
time.

: 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.

Right now it is a set of tools that can be used to build a database of
files that FreeBSD used to have, but doesn't any more.  This is the
most conservative approach that we can take.  Given the unknown nature
of most systems, I think we need to be conservative here.  Also, it
doesn't move things out of the way in such a way that's hard to
recover from should things go wrong in the middle somewhere.  This
list of files can be moved or removed, that nit doesn't really matter
and is really an uninteresting part of the problem: let the user
decide.  The hard part is coming up with this list.

: > 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.

/usr/include isn't too bad, and /usr/share/man is obviously completely
safe since the man pages are available on the web and assuming no
third party software.  /usr/lib is very dangerous and can result in
weird things happening, especially for the case where something bad
happens while installworld is running.

: 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. :)

Yes.  I hope to have something by BSDcon to show to people.  Work has
kept me busier than I'd have liked, and the remaining time has been
soaked up by getting NEWCARD in better shape for 5.2.

Warner