> 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.
> ꀠ嘢k, this may take a while. 糍he basic problem is that a number of
> ꀠ漤atch files in pkgsrc didn't follow the pkgsrc rules on making patch
> ꀠ沲iles and ended up with $NetBSD$ expansions that don't match what
> ꀠ烀as committed to cvs. 糍here is no easy solution from the git repo
> ꀠ澵ide because any corrections we make will cause merge problems later
> ꀠ漑n.
>
> ꀠ啫or the moment a workaround is to 'bmake makepatchsum' in the effected
> ꀠ氽irectories.
>
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