Thanks, Ingo. You make some good points. A few responses inlined below.
On 2/21/18, Ingo Schwarze <[email protected]> wrote: > 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. Yes, but this truism scales upwards. For instance, X Windows pretty much requires a window manager on top of it -- you probably *could* run it without one, or write your own, but these cases are exceedingly rare. That doesn't mean that X and your chosen window manager have to be in the same package -- indeed, it's much better that they aren't. Each package focuses on a single, specific piece of the overall puzzle. > 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. Yes, it's unclear where packages that were written specifically with groff extensions -- I know -mom also falls into this camp -- would live under this proposal. I was thinking more in terms of the classical macro packages that long predate groff and are fairly portable across *roff implementations. -mom is sort of already its own beast, as it has a version numbering system independent of groff's. > 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. This issue is hardly exclusive to groff. Plenty of FLOSS packages have dependencies on specific versions of other packages, and the system's package manager must be aware of which versions of package A are required by package B, often with complex dependency trees. Even with two packages, the groff part of that tree would be trivial. >> 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. I apologize if anything I said could be construed as against Bertrand in any way. I was responding (to a post he made some months ago) to his statement that he was comfortable with the groff code base but not the macro packages. I think a number of people have the opposite skill set. It's fine for all these people to come together under one umbrella and contribute what they can, and that system has worked for decades. I'm just brainstorming alternate approaches. Honestly, I'm not even advocating *for* such a split right now, just exploring the idea. > 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. Indeed, splitting out easier jobs is a time-honored way to help those who have difficult jobs. Your brain surgeon is probably not also answering phones at the hospital's switchboard and managing its cleaning crew. To my view, this *is* a way of supporting Bertrand -- he has graciously volunteered to be groff's brain surgeon, and perhaps we can make his job easier by offloading work he's already said he doesn't feel as comfortable doing. Sometimes it's better to take the "easy" stuff off the plate of those who have to deal with the difficult parts, so they can better focus their attention. > Having to coordinate with > independent macro releases mike even make the task of the core > maintainer more complex... It might, though it seems to me that all the dependencies should go the other direction: macro packages may require specific features in groff, but I'm not sure how the reverse could be true. There may be edge cases I'm unaware of, though.
