svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> --------
> In message <CAPyFy2CEbKMNVUJ6_mthfq3QL6tq5V0jjoZ01eX82-2kwqLFkQ at mail.gmail.com>
> , Ed Maste writes:
> >On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> 
> >Doing some archaeology, the first instance of a uuencoded file I can
> >find is r1796, "Got rid of a couple of binary files by uuencoding.  49
> >more to go." There's no explanation of why the change was made.
> 
> I am pretty sure that we discussed the question of binary files in
> the tree on either core@ or hackers@ (not much difference back
> then), but that probably predates the "Dont mount the projects mail
> archives on /tmp/something" incident.
It would of been hackers@, this would of not been a core discussion.

> The first versions of CTM used diff -e and ed(1) to transmit changes,
> and that choked up on binary files.  We didn't have patch in the
> tree back then.
patch has always been in the tree.
https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch

> 
> I can't answer definitively if modern CTM has any such restrictions,
> but I would not expect so, either way, it should not matter.
Warner said in another reply it does not, but this should be
listed in the decision criteral, with a "not effected or
formally effected" state.
 
> >> We should also note that if they are already in uuencode state
> >> to leave them in uuencode state, or do we intened to convert
> >> them on next commit, or ???
> >
> >Good point, converting existing .uu files to binary is just
> >unnecessary churn and is not recommended. If someone is going to make
> >a change it can be done with the next update.
> 
> Agreed.

So is it leave them forever .uu, on next import/whatever bring
in the binary and remove the .uu, Or ?

> phk at FreeBSD.ORG         | TCP/IP since RFC 956
-- 
Rod Grimes                                                 rgrimes at freebsd.org