Re: /lib symlinks problem?

From: Doug Barton (DougB_at_FreeBSD.org)
Date: 09/01/03

  • Next message: Scott M. Likens: "Question related to FreeBSD Serial Console..." 
    Date: Mon, 1 Sep 2003 12:42:19 -0700 (PDT)
To: "M. Warner Losh" <imp@bsdimp.com>

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

    > In message: <20030901015535.Y3776@znfgre.qbhto.arg>
    > Doug Barton <DougB@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Scott M. Likens: "Question related to FreeBSD Serial Console..."

    Relevant Pages