[Pkg-emacsen-addons] Bug#841524: Bug#841524: Depend or Suggest markdown package for preview to work

[Nicholas D Steeves]

On Sat, Feb 16, 2019 at 04:18:04PM -0400, David Bremner wrote:
> Nicholas D Steeves <nsteeves at gmail.com> writes:
> 
> >
> > List of supported converters from upstream README.md: markdown |
> > libtext-multimarkdown-perl | pandoc
> >
> > Also available in Debian: discount | python3-markdown
...
> > Given that markdown-mode is configured upstream to use "bin:markdown",
> > it seems more reasonable (and easy!) to just Recommends markdown, and
> > then add a list of alternatives to Suggests.  This way it works out of
> > the box, and the user can consult Suggests when interpreting the
> > upstream README.md.
> 
> I don't usually think about Suggests as alternatives to Recommends, but
> rather things less commonly useful, but still enabling additional
> functionality.

That's fair, and I'll confess that my idea for using Suggests in this
way might be hacky...  Also, 'just realised that declaring a list of
optional packages in Suggests might increase the maintenance burden of
this package.

So I guess the wonderful kinda bloated pandoc will not be in Suggests,
even though upstream specifically mentions it, because a) it doesn't
provide /u/b/markdown and won't work ootb.  b) it potentially
increases our maintenance burden.  c) using Suggests in this way might
be hacky?

> markdown, libtext-markdown-perl and discount provide
> /usr/bin/markdown. You could test how well those work ootb, 
> and recommend them as alternatives if it seems ok.

That seems like a solid plan.  In particular, any that fail at
markdown-mode's special support for github flavour can be dropped from
the list of alternative Recommends.  So we'll eventually end up with
one or more recommends, and html export will work ootb.

Rather than manually test these three alternative Recommends, I'd
prefer to enable the upstream self-tests, and then figure out how to
run the suite for each of markdown, libtext-markdown-perl, and
discount.  <- that seems like a fun challenge, with some useful
problems.

> There are also conflicts between several of those, which looks odd to
> me, but I'll investigate that seperately.

Maybe they conflict on the file path /usr/bin/markdown?  I asked
someone on #devel about whether it would be hypothetically reasonable
for markdown-to-html packages to "Provide:
virtual-markdown-converter".  In his/her view, it's not...

Thanks for investigating this bit, very much appreciated!


Cheers,
Nicholas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-emacsen-addons/attachments/20190222/857ff1ee/attachment.sig>