On Fri, 9 Aug 2024 17:47:50 +0200 Bastian Germann
<bastian.germ...@gmx.de> wrote:
> Please see #1072958 for the RM request on markdown.
> It should be replaced with a maintained alternative such as discount.
> You can check the blocking bugs for that RM bug to find the packages
that need some change.
I'm aware of that, and the submitter of the RM bug, while still being
unhappy of the fact that markdown is unmaintained upstream, is OK with
me adopting the package and closing the RM bug.
> I would strongly advise against adopting the package because that
will
> alleviate the reverse dependencies' urge to update.
There's no urge of updating if you're targeting the original Markdown
as opposed to some dialect like CommonMark. Despite not being perfect,
Markdown.pl is a fine implementation. Please see
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466330#115> for some
more reasons why I think that the original markdown implementation
should stay.
On Fri, 9 Aug 2024 19:42:21 +0200 Daniel Gröber <d...@darkboxed.org>
wrote:
> Problem is discount breaks some of my hacky markdown :)
Another reason why keeping the original implementation is desirable!
> I considered suggesting letting the RM go through and just
re-uploading but
> doing it that way seems a waste of ftp-master time. Do you have any
other
> suggestions?
As I mentioned above, the submitter of the removal request told me to
just close the RM bug after uploading the package.
On Fri, 9 Aug 2024 19:55:22 +0200 Bastian Germann <b...@debian.org>
wrote:
> There are so many markdown impementations in Debian, just some
suggestions with executables:
> python3-markdown
> python3-markdown2
> python3-markdown-it
> rust-markdown
> libtext-markdown-perl
> pmarkdown
Not all of these are perfect too. libtext-markdown-perl, for example,
is slow, and has seen its last upstream update more roughly ten years
ago. I don't know about the others. Which dialect do they implement?
How compatible are with the original markdown syntax? Are they a
bug-for-bug replacement for Markdown.pl? Markdown looks like a simple
matter on the surface, but the lack of a canonical specification (which
CommonMark tries to be) makes everything a bit more intricate.
Hope my request looks more reasonable now :)
