> In the GNU/Linux world, many systems (apart from the kernel and
> maybe the coreutils and maybe a very small number of other
> components) consist of a variable set of packages, and each
> distribution, and to a certain extent each user, is free to assemble
> their system from whatever components they want. [...]
Yes.
> In the BSD world, by contrast, the whole system including the
> kernel, a full POSIX compatible userland, and many other base system
> tools is regarded as one indivisable entity, intended to work
> smoothly together as one whole. [...]
Well, in many cases GNU tools provide extensions to POSIX, sometimes
even in incompatible ways, since POSIX is often a compromise, not
necessarily the best solution for a given task. And sometimes POSIX
decisions are really bad, as you certainly know.
> So any package trying to replace base system tools, in particular
> those standardized by POSIX like sed(1) and yacc(1), is regarded as
> pushing unwelcome idiosyncracies. Predictable, here, means "use
> standardized tools, not arbitrary extensions."
Well... groff tries to be compatible to POSIX as much as possible,[*]
but if there are valuable improvements in the GNU world, we shouldn't
hesitate to use them. For example, bison's `named references'
(introduced in version 2.5) are *much* easier to use and understand
than the error-prone `$n' notation.
> Fortunately, we do have solutions to do what we want. For example,
> our ports build system uses these definitions by default: [...]
Nice!
> I just hoped the need for such workarounds could be lessened, but
> apparently, it cannot.
IMHO, this isn't a work-around, this is a valid approach to transform
GNU/Linux conformity to the BSD world.
Werner
[*] This will become even better since we are going to use gnulib
extensively, providing missing functionality for a bunch of
non-GNU hosts.
