mergemaster broken?

Doug Barton dougb at FreeBSD.org
Tue Mar 21 21:22:33 UTC 2006


I'm including rwatson here since the MACHINE_ARCH stuff was his idea.

Ruslan Ermilov wrote:

>> On Mon, Mar 20, 2006 at 03:40:06PM -0800, John-Mark Gurney wrote:
>>> Should we also document that -m is suppose to be src's etc dir instead
>>> of src?  I've accidentally pointed -m at src, and then it does a make
>>> which is quite ammuzing as it's completely the wrong thing...  Or now
>>> that we call outside of /etc, should we make -m really point to src,
>>> and have the proper calls add etc to the directory?

I strongly dislike the idea of changing the semantics of the -m option. It's
been the way it is since day 1, and I really hate to make changes to
something like that. I can see a case for making the man page more clear,
but I'd rather work around the problem with -m than change the semantics.

> Doesn't really matter, mergemaster(8) was broken because it was
> written when we didn't have correct wrappers for "distrib-dirs"
> and "distribution", upgrade and cross-arch friendly, at the top
> level.
> 
> Anyway, attached is the patch I'd like to commit after a nod
> from Doug.  It fixes mergemaster(8) to use src/Makefile wrappers
> for distrib-dirs and distribution targets, and makes it use
> TARGET_ARCH instead of faking up MACHINE_ARCH, now that it uses
> the correct wrappers.  It also makes ${SOURCEDIR} and -m point
> at the src/ top, as documented in a manpage.

Forgive me if I'm being dense here, but why do the changes you describe
require that we run make in src/? Or, alternatively, if it is _absolutely_
necessary to do so, why do we have to redefine SOURCEDIR to be src, and why
can't we just strip /etc from SOURCEDIR where needed?

In short, I have no objections to fixing mergemaster to work with the new
world order, but it needs to be done in a way that does not change semantics
of an existing option. I'd also like confirmation from Robert that we're not
breaking any of the behavior that he added by doing it the way you propose.

Thanks,

Doug

-- 

    This .signature sanitized for your protection


More information about the freebsd-current mailing list