> I guess if someone writes an automated script he/she will have to deal
> with things like
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/tcpd/Makefile.org
> or Makefiles in test/debug subdirs anyway... maybe it's better to have a
> well-known "black sheep" in the tree than having no one.
I don't find this argument compelling. The black sheep are all nuisances;
tcpd/Makefile.org looks like a mistake.
> > I remain strongly opposed to alien Makefiles in our tree.
>
> Umpf... if the argumentation above isn't convincing enougth (yes, yes...
> it isn't _that_ funny... ;-/ ) - how should we proceed in this case ?
> Removing the file is bad because it would generate the "precedent" to
> get more files stripped and renaming isn't much better (well, it isn't
> that bad (compared to the ide to get files removed) ... we adjust the
> paths of the parent directories in the diff files anyway and doing this
> for the Makefiles may not hurt... but I fear which possible "precedent"
> could be constructed from that (like "... lets rename all files which
> are unused from ${i} to ${i}.unused ..." or something like that) ... ;-(
> ).
With the exception of the tcpd blunder above, I think we are asking for
existing precedent to be followed (though this precedent is admittedly not
officially stated). That precedent is that Makefiles and other files that
are alien to the way ON is built need to be stripped from the upstream
source as part of bringing it into ON. By extension, files that would
only be consumed when the source is built in an alternate fashion (e.g.,
Windows-specific source files) should also be stripped out if it is
apparent the file is unlikely to ever have relevance to Solaris.
Personally, I'd think the "by extension" part would be at the discretion
of the team bringing the source code in. But at the same time, the team
needs to keep in mind that thousands of people interact with the ON tree
and will feel the second-order effects of piles of alien cruft.
--
meem
