Hi, Dave Kemper wrote on Wed, Feb 21, 2018 at 02:26:15PM -0500:
> Does it make any sense to split groff into two packages: one that is > just the base groff system, and one that is just the macro sets? I don't think it makes much sense. You can hardly use *roff without macros (well, there are rumours about a few people using their very own, personal macro sets, but that's certainly the exception rather than the rule), and the macros almost unusable without groff. To provide just one example, i don't think that the groff_mdoc(7) macros would stand any chance of working with any other groff implementation. They may heavy use of groff-specific post-1.17 features. > - As Bertrand points out, from a maintainership point of view, the > skill sets are disjoint. Someone skilled in C/C++ code might not be > as strong in groff macros, and vice versa. I would have been quite an inconvenient situation for the mdoc rewrite by Werner Lemberg and Ruslan Ermilov in the past. It would have required to first make a groff release, wait so time and hope that people upgrade, then release the macros using the new features. And no doubt so people would have tried using the new amcros with an old groff release, with bad results. Version management is certainly easier, both for users and maintainers, when you distribute the macros together with a version they actually work with. > - The classical macro sets predate groff and are not exclusive to > groff. If some groff macro set works with some other *roff implementation, there is nothing wrong with installing both roff implementations - and use that macro set, even if distributed with groff, with both. That works already now, it doesn't require any splitting. Just like you can use third-party macros with groff, if they are portable enough to work with groff. > I can think of several longtime list members who would be > excellent maintainers for the macro packages but who probably don't > know the first thing about the C++ code that drives groff. And > Bertrand has already stated he's in the opposite camp. I see nothing wrong with supporting Bertrand. He has already proven that it is quite easy and pleasant to work with him. Sure, maintaining macro sets is an easier task than maintaining the complicated automake / autoconf / C++ beast as a whole. But i don't see how splitting out *easier* parts could possibly help with maintaining the harder parts, and even less so with keeping the thing as a whole in good coordination. Having to coordinate with independent macro releases mike even make the task of the core maintainer more complex... Yours, Ingo
