Re: mergemaster broken?

On Tue, 21 Mar 2006, Doug Barton wrote:

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

See, this is why I should never touch source code. :-)

> 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.

I've always thought it was a bit odd that it pointed at etc, but agree that my 
fingers are now used to it.  I wonder if thre's a middle ground here where we 
add a new argument, and if you use the old one certain things don't work (and 
you get a warning)?  It has always struck me that mergemaster really should 
build from the top-level src so it gets the full context, although that's been 
less important in the past.

>> 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.

The user only sees the architecture argument, so changing the underlying 
method for selecting the architecture with respect to the makefiles is fine by 
me.  In fact, there is the potential for much betterness with ru's proposed 
changes, since mergemaster can rely on buildtools, and that in turn means that 
mechanically generated content in /etc can be generated using properly 
targetted tools.  For example, when building binary versions of login.conf.db, 
aliases.db, etc.  And for the TrustedBSD work, supporting SEBSD build tools 
for the target would be very good.  We've always been in a bit of a sticky 
situation because mergemaster ran using the native tools on the system, not 
the target tools, so you couldn't rely on new tools, such as policy compilers, 
to build parts of /etc.

So while I don't have opinions about the implementation details, I think what 
Ruslan is proposing is architecturally the right thing.  How to handle the 
command line argument, I don't have an opinion, except that user surprise is 
bad, so a new argument with some compatibility and a warning is probably 
better than changing "-m".

Robert N M Watson