pkgsrc and 2.8

[Samuel J. Greear]

>    If we are going to do this, NOW is the time.  Comments?

As you already know, I am for this. I don't think auto-merging is
strictly necessary. It is certainly worth a try, we can cross our
fingers and hope it just works, but I think the real benefit will be
having a large/working/stable set of packages to go along with each DF
release.

There are simple things we could do to ensure the merge process never
broke, for instance, we could only ever add files to the patches
folder, and we could prefix the filenames with DragonFly. We should be
able to solve all of our problems in this fashion, even if a small
Makefile change or such would be easier in many cases.

>    Ok, this may take a while.  The basic problem is that a number of
>    patch files in pkgsrc didn't follow the pkgsrc rules on making patch
>    files and ended up with $NetBSD$ expansions that don't match what
>    was committed to cvs.  There is no easy solution from the git repo
>    side because any corrections we make will cause merge problems later
>    on.
>
>    For the moment a workaround is to 'bmake makepatchsum' in the effected
>    directories.
>

If we somehow handle/filter the $NetBSD$ expansions and commit that
result on top of what we have now, bringing us up to exactly the
current state of pkgsrc, and we always handle/filter things that way
in the future, I don't see how we will run into merge problems?

At any rate, I don't think disabling checksums globally on patches is
probably all that wise. In the absence of a good solution, perhaps the
best way to go would be to roll v3 like we just rolled v2 of the
pkgsrc repository. Planning for the future, and knowing that we may
run into a problem or two down the road that will require us to roll a
v4 or v5, if we do this perhaps we could draw a line in the sand wrt
history, keeping at least the initial repository small?

Sam