Re: groff package in MSYS -- pdfroff fails dismally

On 03/05/12 03:55, Charles Wilson wrote:
Thanks.

Debian have a long standing history of rejected groff patches, to the
extent that they locked their users into a 5+ year time warp, stuck at
groff-1.17, when the rest of the world had already progressed to 1.20.
(Most of us just ignored the APT repository, and built from source).

The problem with distro-specific patch sets is precisely that ... they
are distro-specific.  What works for Debian may be, (and very likely
*will* be), inappropriate for MSYS, (or indeed, any other distro).

> Obviously, as the code owner, you'd perceive the use of any patch,
> previously rejected (by you!) as "calling your baby ugly".  Me, I don't
> care: if it fixes a bug -- even if the overprotective, defensive
> upstream maintainer rejected it -- then it's good. Not "pollution".

Except, that I didn't reject them out of any sense of pride in the
original code; I rejected them because they were *broken* on other
platforms, on other platforms on which I personally use groff, (of which
MSYS was just one).

> The question here is: do all 20 of the included debian patches fix
> actual bugs or provide measureable, desirable improvements on the MSYS
> platform -- or not?
>
> I think the answer is 'no, not all -- but maybe some do'.  This should
> be a case-by-case decision, not a blanket "let's just use pristine FSF
> sources" -- because we CAN'T.  Natively building groff on MSYS won't
> work; at least, 'make install' won't, thanks to the $(LN_S) problem.

$(LN_S) used *not* to be a problem; AC_PROG_LN_S used to set it to
`ln -s' on MSYS, but it now seems to choose `cp -p' instead; `ln -s'
works fine, but `cp -p' doesn't.  Furthermore, this is only one of two
issues I never encountered before, building stock FSF groff-1.20.1 for
MinGW on MSYS, but which I do encounter today; see below.

> Even if you arrange for $(LN_S) to be defined as 'cp -a' that's not
> ideal, since msys-lndirs is more preferable as it recreates the dir
> structure while replicating files as hardlinks rather than copies.

msys-lndirs is a newer addition, which wasn't available when I first
built and installed groff-1.20.1 for MinGW, IIRC.  In any case, `ln -s'
works fine; doesn't that also make hard links if possible?

I'm objecting to #1 and #2, *without* declaring the dependency in
mingw-dist.  I'm further objecting to #2 because I've already patched
upstream in a much more robust (and portable) manner, such that mktemp
will be used IFF it is available, but there is a fall-back if not; (the
lack of such fall-back was my principal gripe with the Debian patch).

> and (b) using mktemp does appear to avoid an existing race
> condition, which an attacker could exploit.  OTOH, why are we worried
> about $TMP races -- on MSYS, where permissions are wide open?  It's not
> like windows is so secure that anybody who could exploit a $TMP race
> couldn't do much more damage already, using some other vector.

Exactly.  When asked to review the patch, upstream, I felt that it was
excessively paranoid, but that's not why I rejected it.  I rejected it
because it was fundamentally broken.

> #3 adds -DSAFER when invoking gs, which seems like a reasonable thing to
> do.

That's fine.  The benefit is questionable, but it wasn't contentious; I
accepted it, upstream.

> #4 removes unnecessary bashisms from some sh scripts

Which I do support.  I'm mildly surprised that there are any such within
the core groff code, because Werner is usually pretty assiduous in
filtering them out.

> #5 use POSIX signal names in trap statements, rather than numbers. A
> posix shell is required to support the names, since the signal numbers
> might differ depending on platform (even tho they don't, in practice).

And I rejected this too; the POSIX trap names aren't universally
portable, even to some of the Unix platforms I have, (or have had),
occasion to work with.

> #6 forces some other "sh" scripts, which require bashisms, to run under
> bash instead of sh.  (Yes, I know our sh.exe is actually bash, but bash
> operates differently when invoked under that name: "If bash is invoked
> with the name sh, it tries to mimic the startup behavior of historical
> versions of sh as closely as possible, while conforming to the POSIX
> standard as well.").

This is the reverse of #4; I'd prefer *no* scripts to depend on bash, in
the first place, but I've never experienced the slightest problem with
running any of groff's scripts under MSYS bash, even when it is
masquerading as sh, (not that I routinely use many of the peripheral
scripts, apart from pdfroff, anyway).

> #7 replaces 100 lines of awk with one line of perl.

That's a neat trick!  How *do* you squeeze 100 lines of awk code into
a shell script, which itself comprises only 60 lines in total?

> Sounds good if you always have perl, but I think MSYS-groff would
> prefer a lighter executable footprint, and keep the 100 links of awk.

For what purpose, exactly?  I disagree that perl is, in any way, to be
preferred to awk anyway, but why introduce a dependency on perl, for a
script used *exclusively* at groff *build* time?  Sheer insanity!

> #8 works around a bug that appears when dash is used as sh (it's unclear
> whether the bug is in the script, or actually in dash). As we don't use
> dash as sh, maybe this patch isn't needed. But it does no harm.

Ack.

> #9 Using '+' in sed expressions as a metacharacter assumes GNU sed.  So,
> this patch is pedantically correct...but msys-sed IS GNU sed. So it
> doesn't matter.

Yet, groff is known to build and run cleanly on many disparate systems,
including many which don't have GNU sed ... but as you note, for us, it
hardly matters.

> #10 /bin/awk -> /usr/bin/awk.  Makes no difference on msys, so could be
> dropped

A distro-specific.  Doesn't affect us either way, so irrelevant.

> #11 Looks pretty old, and even debian questions the need for it nowadays.
>
> #12 I think this has already been merged into newer upstream.
>
> #13 Adds a few missing FreeBSD and POSIX version strings.  Probably a
> no-brainer merge upstream, but don't know if it has happened yet or not.
> Does it matter for MSYS? dunno.

AFAICT, mostly as shorthand for use when compiling distro-specific
manpages; probably irrelevant for us.

> #14 Reference GNU FDL

The stock manpages, from upstream, already do this in a generic manner,
(including the canonical source reference).  This patch is yet another
distro-specific, to point to an installed copy.  And, as you've noted
elsewhere, if we don't just keep it generic, then we need a *different*
distro-specific patch.

> #15 We don't ship pic.ms[.gz] or pdfmark.pdf[.gz], so we probably don't
> need to change the names in the man pages that refer to them.

Take that a step further.  If we don't furnish them, to what are you
actually referring, when you apply the patch?

> #16 Description: Adjust default recursive make targets
>     This has been in the groff packaging since records began, and
>     the reason for it is unclear.  Needs investigation.
>     -- so not even debian remembers why they do this. Drop.

Agreed.

> #17 Inhibit -wmac warnings due to pic and eqn
>     Define .PS and .PE to empty strings in pic output to inhibit -wmac
>     warnings; similarly, define .EQ and .EN to empty strings in eqn
>     output.
> Fixes http://bugs.debian.org/495713
> Keep?

Dunno.  I do know that I use both pic and eqn, and I appreciate the
warnings if I misuse the macros; I'd be inclined to drop this, but it's
probably harmless either way.

> #18 Description: Allow adding a version-independent directory to the
>     macro path. This allows us to put /usr/share/groff/tmac at the end
>     of groff's macro path in Debian.
> That seems reasonable; it's a place where version-independent macro
> packages -- or custom-written ones -- can be installed. Keep?

Seems extremely questionable to me.  We already have standard locations
for macros shipped with groff, (which are always installed as version
specific, even though most probably aren't), and a separate `site-tmac'
directory for custom, (version-agnostic, site-specific), additions; if
any others are needed, $GROFF_TMAC_PATH is entirely sufficient to
specify them, perhaps even on a project or document specific basis.
Besides this, there's also the -M command line switch, (analogous to
GCC's -L), to add more on-the-fly.

> #19 Description: Use /etc/papersize in preference to configure-time
>     selection
> This lets me set papersize to letter, and Keith to A4, without having to
> recompile groff.

Which is mostly pointless; I can choose the paper size on-the-fly, with
appropriate command line switches, (and I've always found this to be the
most reliable way to specify my preferred paper size).  If I do want to
change the default, I can just as easily edit the output device
configuration file as I can /etc/papersize; (and then I know precisely
to which output device that configuration will apply).

> Should probably add an /etc/defaults/etc/papersize file to the
> msys-groff package, with a lua preremove/postinstall pair to copy it to
> /etc $if-not-exist-and-not-modified.

Seems like too much effort, for too little gain, to me.

> #20 Description: Display more helpful output when failing to load a
>     device.  If the device is known to be one of the devices in the
>     groff binary package rather than groff-base, refer the user to
>     that.
> Hmmm...should probably implement a custom version of this patch for
> MSYS, since (a) our two package names are different (groff-bin +
> groff-ext vs. groff-base + groff), and (b) our groff-bin perhaps
> contains a different set of devices than their groff-base (not sure;
> haven't checked).

Dunno, and don't have sufficient incentive to follow up.

> #21 Not needed if #14 is dropped; needed otherwise.

Your choice.  How many of our user's will even consult the groff
manpages, much less the FDL?  How many will care whether we keep the
generic wording, or give them an explicit reference to a local copy.

> #22 Needed to deal with MSYS peculiarities.

Maybe.  See below.

If you say so.  I've now ditched msys-groff, as being too utterly borked
for any serious typographic work on MSW.  I've reverted to a native
MinGW build of generic FSF 1.20.1, which is altogether a much more
robust option.  (FWIW, I couldn't get 1.21 to build -- looks like some
of Bruno's updates, and/or gnulib additions, may need some more
effective autoconf probing).

BTW, groff-1.20.1 used to build and install OOTB, on my old win2k box,
when it was first released.  Something seems to have changed in the
meantime, either in the MSYS arena, or with my enforced upgrade to
Vista.  It still *builds* OOTB, when configured with:

  $ $SRCDIR/configure --prefix="`cd /usr/local; pwd -W`" PAGE=A4
  $ make

but it doesn't *install*; the first issue is that MSYS install-info now
seems to choke on the `c:' at the start of `$prefix', which I *can* work
around with:

  $ make prefix=/usr/local install

only to trip up again, at the final hurdle, because `cp -p' can't copy
*directory* `$(VERSION)$(REVISION)' to `current', (which I can also
successfully work around with:

  $ make prefix=/usr/local LN_S='ln -s' install

so something appears to have changed in the AC_PROG_LN_S detection on
MSYS, since I last built groff-1.20.1 on win2k).

--
Regards,
Keith.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr