Hi Jan, Jan Stary wrote on Mon, Jul 01, 2013 at 05:47:41PM +0200: > On Jun 29 15:08:12, [email protected] wrote: >> Jan Stary wrote on Sat, Jun 29, 2013 at 02:28:55PM +0200:
>>> Certain ports require groff because that's what >>> their manpages are written for. >> Manuals specifically written for groff (as opposed to for roff in >> general) probably exist, but i don't think that's the majority of >> manuals requiring groff. Rather, i'd guess that most manuals >> requiring groff in OpenBSD ports use low-level roff formatting (in >> addition to man(7) macros) that is supported by most roff >> implementations, not just by groff. > Yes; where I said "manpages for groff", > I should have said "the legacy manpages". That's even more wrong. Most legacy manuals do not require groff but work fine with mandoc. Most manuals that do not (yet) work with mandoc just use fancy low-level roff(7) requests because the manual author (or the author of today's code generation tool the manual author chose to use) thought mixing in fancy low-level stuff would be cool. Lots of the stuff that breaks is not old. > The example I originally had in mind was mail/procmail. I may have a look at that later, i have too little time right now. I'm sending this quick answer anyway such that you don't set off into the wrong direction. >>> Is that generally >>> possible? Is an mdoc(7) manpage, when written >>> with compatibility in mind, acceptable for upstream >>> that originaly wrote the manpage for groff? >> That depends on the taste of the upstream developers. >> I think moving from man(7) to mdoc(7) and using -Tman >> makes manuals better, but some upstream projects will >> certainly disagree - or simply not care at all. > Reading > http://www.undeadly.org/cgi?action=article&sid=20100604082319&mode=expanded > specifically Kristaps' > > Lastly, if one's manuals are in -man format, for gods sakes > re-write them in -mdoc format! That's overly optimistic. At the time Kristaps wrote that, it wasn't a realistic option for portable software because mandoc -Tman didn't exist yet. Nowadays, with a bit of care, it can be done, and it isn't rocket science, but because it requires proper use of mandoc -Tman, it is still not completely trivial. Kristaps is sometimes quite excited about nice things and tends to ignore all those pesky little problems related to details somewhat. :-) > is what got me into this. I will try to find a small > man(7) page of a GROFF-dependent port I care about > and try to persuade upstream to let me rewtite into mdoc(7) > and see how that goes. Oh well, but please make sure *first* you yourself understand thoroughly what you are talking about. Right now, that doesn't seem to be the case, yet. Misleading upstream projects into *about* the right direction but subtly mixing the education with bad advice is *not* helping. Let me be clear about that: Before you know both the man(7) and the mdoc(7) language very well, have a very good understanding of their strengthes, weaknesses and differences, and have quite some experience writing mdoc(7) code of good quality, you should not attempt to educate upstream, or it will end up in confusion and anger. > Or is there something in base still not converted to mdoc? Why not search for such files yourself? Watch out for lines starting with .TH. But make sure you exclude files maintained upstream. Converting stuff in base would be counter-productive if that causes headaches for the next update. In particular, the following should not be converted: - Perl stuff - binutils - any gcc versions - curses - GNU cvs - bind and nsd - lynx - OpenSSL - ... maybe more ... I wouldn't be surprised if all the work has already been done. Yours, Ingo
