> On 5/2/2012 9:26 AM, Keith Marshall wrote:
>> Where did you get the source for the groff-1.20.1 in MSYS?
> Upstream groff-1.20.1, plus debian-1.20.1-9-patches, plus
> 1) 01-doc-gfdl-msys.patch
> Say "MSYS" instead of "Debian" in man pages (debian 'doc-gfdl.patch'
> added a reference to "Debian" while pointing to the GNU FDL).
> 2) 02-msys-install.patch
> Use lndir instead of symlinks, when replicating $(version)$(revision) as
>> I ask because, while setting up a new machine at work, I thought that
>> I would give it a try, rather than seek out a backup of my own native
>> build, but after
>> mingw-get install msys-man-bin
>> mingw-get install msys-groff-doc msys-groff-ext
>> and having also installed the PortableApps.com version of GhostScript,
>> pdfroff refused to run, (failing on a mktemp command invocation).
>> Now, I *know* that pdfroff isn't *supposed* to require mktemp; (I know
>> this because *I* am the original author). On investigating, I notice
>> that the pdfroff in msys-groff-ext includes a Debian patch which I
>> rejected upstream; I rejected it because I knew it was going to break
>> any platform which didn't provide mktemp, (and, at the time, MSYS was
>> one such platform).
> I generally have had good results for many packages, on both cygwin and
> msys, by picking up patchsets from debian or gentoo (or even sometimes
> Red Hat or Mandriva) since the distros generally update their packages
> on a more rapid basis than any 'upstream'.
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).
> It appears that may not necessarily be true in this case; looking closer
> I can't really see any reason to prefer the giant 'perl.exe' to the slim
> 'awk.exe' -- even if it simplifies mdate.sh to a single line.
> Not to mention your aforementioned mktemp problem.
>> I know we do, now, provide an msys-mktemp implementation, so the Q&D fix
>> could be to add the dependency to msys-groff-ext, but I really would
>> prefer a distribution based on original FSF source, not polluted by
>> inappropriate Debian patches;
> Ah, see now here's where we disagree. You have a more intimate
> relationship with the groff source than I do -- but from my third party
> perspective there's no immediate reason to characterize using a
> well-tested distro's patches as "polluted" or "inappropriate".
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
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.
> #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
> #10 /bin/awk -> /usr/bin/awk. Makes no difference on msys, so could be
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*
> #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.
> #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
> 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
> 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
> 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.
> So, my analysis is we should drop
> 1 2 7 8 9 10 11 12 14 15 16 21
> 3 4 5 6 13 17 18 19 20 22
> (but #20 should be rewritten custom, and #19 implies some additional
> packaging enhancements). And naturally this entire analysis changes if
> we bump to
> groff-1.21 +
> http://patch-tracker.debian.org/package/groff/1.21-6 >
> Anyway, this is certainly not the same as "just use pristine FSF sources".
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
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
$ 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).