On Sat, Feb 16, 2019 at 04:18:04PM -0400, David Bremner wrote: > Nicholas D Steeves <nstee...@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
signature.asc
Description: PGP signature
