Re: [groff] mom: blockquotes lose indent across page breaks

[Ingo Schwarze]

Hi Peter,

Peter Schaffter wrote on Tue, Dec 18, 2018 at 01:41:45PM -0500:
> On Tue, Dec 18, 2018, Ingo Schwarze wrote:
>> Peter Schaffter wrote on Mon, Dec 17, 2018 at 08:55:04PM -0500:

>>> I've updated mom-2.4.tar.gz on mom's website,

>> Never change tarballs after they are released.
>> That causes bad trouble to downstream packagers:

> The tarballs aren't, and never have been, for packagers.

If you publish a release of some free software, whether or not it
will be packaged is a downstream, not an upstream decision, and
policies about what to package, what not to package, and how to
structure packages are considerably different among operating systems
and package management tools.  However, changing published releases
after the fact is likely to cause trouble for all these systems,
and even more so for users getting it directly from your website.
How are users supposed to know what they have is buggy if you don't
bump the version number and don't announce a new release?

Publishing a software release and then saying "it shall not be
packaged" is akin to publishing a book and then saying "it shall
not be sold in bookstores, you can only get it directly from me".
Whether or not bookstores carry it is not your decision.

> The "distinct from groff" nature of mom development means that
> any "packaged" version will be the one from contrib/mom when groff
> is built.  Tarballs are posted so users can update mom without
> having to pull groff from the development branch. 

Many packaging systems strongly discourage users from attempting
to update *parts* of packages they have installed, circumventing
the packaging system, because that defeats the whole purpose of
having a packaging system in the first place.

> The two (i.e. contrib/mom and the tarballs) are always in synch,
> but packagers are not expected to use the tarballs, and indeed,
> none have.

If i were aware of even a single user of mom on OpenBSD, i
certainly would.  There are two ways to do it, both trivial:

Either comment out the files contained in the mom tarball
from the groff packing list and make a separate package which
depends on the latest groff release.  That's the more conventional
way, but it has the downside that users must install the mom
package in addition to groff if they want to use it.

Or add the mom tarball as a second distfile to the groff port
and bump the groff packaging version (in this case, from
groff-1.22.3p12 to groff-1.22.3p13) when there is a new mom
release.  In this particular case, that's probably what i would
do, because it is better that every groff installation includes
mom out of the box, and there is no harm in bumping the groff
packaging version when there is a new mom release.

Either variant would profit from proper mom version numbering.

> Every once in a while, as presently, mom presents a bug whose fix
> is so small that it doesn't warrant a version change

That's one thing third digits in the version string are widely used for.

> but does need
> to be made available to run-of-the-mill users immediately.  A patch
> applied to version N.N rather than a release of version N.N-x, as it
> were.  In such cases--extremely rare--the patch is applied to the
> development branch of groff/contrib/mom and the "users' tarball"
> is silently updated.  Since no one is packaging mom for shipment
> separately from groff, concerns about downstream packaging aren't
> relevant.
> 
> Mom began life entirely separate of groff because of groff's
> slow release cycle.  I got a couple of requests from Debianites
> wanting to package her, and a proposal from Werner that she become
> part of groff.  I chose the latter despite the headache of the
> groff-packaged version perpetually lagging behind the latest mom
> release, a problem solved by posting the tarballs.  Though mildly
> unconventional, this pragmatic solution has worked without a hitch
> for over ten years.

Even if unpackaged, keeping bugs secret still harms your users.

But i admit that the discussion about packaging requirements can
be postponed until some system actually packages mom, if you prefer
to not bother with it now.

Yours,
  Ingo