Hi Dave, Dave Kemper wrote on Wed, Feb 21, 2018 at 06:18:40PM -0500: > On 2/21/18, Ingo Schwarze <schwa...@usta.de> wrote:
>> 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. The example doesn't really apply: There are dozens of different window managers, some of them of similar size as X itself and with larger teams than X itself (GNOME, KDE, ...) - of course it wouldn't make sense to include all those - or even any of those large ones - into X. But groff only has a handful of macro package, all of them are very small, even if only compared to the rest of groff which isn't large either, and the total number of active developers on all macro packages combined is - about two or so? > 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. As a matter of fact, the Xenocara distribution (X11 in OpenBSD) does include two window managers, one of them tiling: fvwm1 and cwm. Both of them are tiny compared to the rest of X, and it is very convenient that they allow using X out of the box without installing any other package. In fact, i am using fvwm1 and i'm happy with it, and with the fact that i don't need another package. Of course, poeple are still free to install huge additional packages in addition if they want them, like XFCE or GNOME or KDE, but it is really nice that it is not required. For groff, the situation is even clearer: It costs almost nothing to include the full set of all free macro packages that have been in wide use during the last three decades. If there is an active maintainer for a given package, it causes no friction for that person to provide independent, intermediate releases of that macro set alone, like Peter consistently shows with mom. Sure, there are proven ways to deal with dependency chains, but those are simply not needed here, the task at hand is much simpler. [ snip ] >> 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. Like the core groff manual pages only building with groff (including the groff man macros) and with no other roff interpreter, to name just one obvious example? Oops, now we have a cyclic dependency right there. Bummer. If there is no real need to manage dependencies, your life is simpler if you just don't do it. My point is to keep things simple when complexity can easily be avoided. Yours, Ingo
