>>>> Rather than using this particular mtree file when installing,
>>>> [maybe create a custom mtree] file which will create only the
>>>> required directories and not touch things such as, say, /usr/src?
>>> Send-pr your suggested change :-)
>> When I sent in a PR on that subject [...]
> Unless you sent more than one PR on this subject, the one that you
> _did_ send (1956) said nothing about the perms on dirs in /usr/src.

(Neither did the person who initially grumbled above - that person
mentioned only /usr/src, not any subdirectories thereof.  Check
etc/mtree/4.4BSD.dist and you'll see that /usr/src is one of the
directories listed therein, and I feel confident that mtree will
therefore "correct" the mode bits on it if they aren't what it likes.
(Confident enough that I haven't even bothered trying it.))

> It talked _only_ about making a few extra junk directories...

That was the only immediate problem _I_ had with it.  If I cared about
the mode bits on /usr/src - and disagreed with 4.4BSD.dist about what
they should be - I would have griped about that too in the PR.

You say that as though it invalidated my remarks.  Is that to say that
if I had mentioned that the mtree run is fascist about what the correct
mode bits on /usr/src are, mycroft (or whoever) would _not_ have just
closed it with a "this is how it's supposed to work"?  I find that hard
to believe, yet I can't think of any other sensible construction to
place on your remark.

The basic idea of my PR, I thought, was that it's all very well to
ensure that the directories that are about to be installed into exist,
but it is *in*appropriate to bash mode bits, create directories that
aren't needed, or otherwise do anything else.  Depending on what the
semantics that are supposed to be attached to the various targets in
/usr/src/Makefile are (AFAICT these aren't documented anywhere), the
bug is that make install uses it, that make build runs make install,
that there's no way provided to update an existing system, or whatever.

Perhaps I was unclear in writing that PR.  If I rewrite this message as
PR and send it in, am I to understand that I can expect anything other
than it being closed out with "this is how it's supposed to work" the
way #1956 was?  I hadn't sent in anything else because I don't like to
generate noise PRs; they don't do anything but annoy the people who
have to handle them, who have better things to do.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu