Re: diffutils upgrade

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:This patch will upgrade diffutils to 2.8.1, before you patch your source
:with it you probably have to remove config/diff.
:
:Commit in 3-4 days if noone experience any breakage with it.
:
:http://eirikn.kerneled.com/dragonfly/diffutils-2.8.1.diff.bz2
:
:What is the preferd way to commit it? Using cvs (add|rm|commit) og cvs
:import?
:
:--=20
:Eirik Nygaard

    Ok, a couple of things here.  

    First, great work on the patch!

    For future reference, do not try to specify a patch for an official
    archive that we are importing almost verbatim.  Instead just specify
    the official archive and provide a script to remove the files that
    aren't going to be used after it has been unpacked.  No biggy, but it
    took me 10 minutes to get your patch to apply properly due to the fact
    that it isn't really a proper patch.

    The official dist unpacks as diffutils-2.8.1/...  I am thinking that we
    should use contrib/<NAME>s that are in fact exactly how the official
    package would unpack (at least when such distributions use reasonable
    names).  This way we can update official packages simply
    by unpacking a new one into contrib/, revectoring our build, and then
    cleaning up the files for commit and later on physically removing the
    older version from the repository (and by that I mean I would actually
    rm -rf the older third party software from the repository and just
    leave empty directories so people's cvs trees update properly).
    This way if someone needs to revert to an older source base whos
    contrib physical files have been removed, they can just unpack the 
    original contrib archives in contrib/ and not even worry about cleaning
    up the files that would otherwise not be included in our version, and
    build an older system.

    So instead of trying to modify contrib/diff, leave contrib/diff alone
    and put the new diffutils in contrib/diffutils-2.8.1, which is how the
    official archive would unpack.

    The remainder of your patch would then, as it currently does, patch
    our build tree to compile the new diffutils.  We wouldn't rename the
    build tree :-).

    So why do I want to do things this way?  Well, it's a solution to an
    age old problem that the FreeBSD tree has which is the amount of old
    vendor junk building up in the CVS tree due to unfortunate choices in
    how to treat contrib/ directories.  By normalizing contrib/ the way we
    are, we make it a whole lot easier to understand and maintain third
    party code.  In fact, eventually we may do away with contrib/ entirely
    and make the buildworld download those portions in the same manner that
    ports downloads .tar.gz's of third party software as a 'base'.

    This should not be too much work for you... you already have the 
    official dist pared down properly, it's just a matter of renaming the
    directory and revectoring the build tree to use the new path and then
    committing the mess.  Leave the original contents of contrib/diff alone,
    I'll physically remove it from CVS once we have switched over.

						-Matt