Re: groff inquiry
Daniel Quinlan asks:
> 1. Should the Debian groff package include backwards-compatibility
> symlinks for the binaries?
I disagree strongly, at least for most of the links Dan listed.
Where programs are substantially compatible they should be made
available by the traditional names.
This is because a command name identifies not a program
(implementation) but a service (interface). One should not change the
name of the service because it is being provided in a different way.
> I think including these links is a *bad* idea for a number of reasons:
I'll only answer those I feel like answering ... :-)
> . Programs are not equivalent and, in some cases, behave radically
> different, from non-GNU troff packages.
If and when programs are radically different - ie, most input files
are mutually incompatible - they should have different names.
Hence the difference between (say) Emacs and vi.
However, if the functionality and input file formats are substantially
similar they should have the name.
Anything else will lead to us abandoning the alias `cc' for GCC, for
example.
If we need a shell script to give the command the right option, so be
it.
> . Many commands are left out woefully left out in the list of
> symlinks because groff "offers that much more". (Linking only
> about half and ignoring the rest!)
Err, what ? There's no point linking Groff-only programs to names
without the `g', as the interface here is named by the Groff name, not
the Unix name (because there isn't one).
> . Not a significant cost in loss of compatibility.
This isn't true. Some programs will need to be reconfigured,
especially Makefiles. We shouldn't force ourselves to do this unless
there's a reason to do so.
> . `groff' front-end program obviates the need for using most of
> these programs. It is highly recommended that it be used, as
> well.
We should provide at least all the links that are `commonly used'.
This includes at least nroff, troff, eqn and tbl, as these are used
for formatting manpages (the names eqn and tbl must stay the same,
unless we want to hack up our man program to cope with adding a `g'
..)
> . Forcing the "g", makes people realize that it is a very different
> program from AT&T or BSD troff (C/A/T or ditroff).
But it isn't true ! If I have a file for some random roff I'm likely
to be able to format it unhindered using groff, provided I have a
compatible macro package.
> . Options and processing are different enough that backward
> compatibility can't be assumed anyway.
This is true of many GNU binaries (and hence many Linux binaries) -
certainly in the case of things like cc vs. gcc.
I agree with Charlie Brady's point:
> I favour having something there that will work most of the time
> rather than nothing - which will work none of the time, of course.
Ian.
PS Sorry about the delayed response.
Reply to: