[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new dependencies for pandoc 1.14


Am Freitag, den 29.05.2015, 02:01 +0200 schrieb Jonas Smedegaard:
> Quoting Joachim Breitner (2015-05-29 00:25:12)
> > Am Donnerstag, den 28.05.2015, 17:48 +0200 schrieb Jonas Smedegaard:
> >> [sent again to the other (correct?) list]
> >
> > definitely correct now :-)
> >
> >> Pandoc 1.14 have some new and tightened dependencies:
> >> 
> >>   highlighting-kate >= 0.6 && < 0.7 (0.5.12 is too old)
> >>   cmark >= 0.3.3 && < 0.4 (new)
> >> 
> >> Would be really appreciated if someone could update/package those.
> >
> > I’d like to follow the Stackage LTS haskell releases, which ship pandoc
> > 1.13. Is that something you could live with?
> What doe that really mean?  How often is "LTS haskell releases" updated?

I believe they are aiming for major releases every 3 months currently.
So much faster than a typical Debian freeze :-)

> I would prefer to not be tied by that.  I can imagine how it probably 
> makes sense to generally follow such more conservative pace, and for 
> reverse dependencies of Pandoc it might make sense to convince upstream 
> author of Pandoc to code more flexibly instead of upgrading them - but 
> for Pandoc itself I would really appreciate not being locked down by 
> conservative constraints if possible - there's a long range of 
> improvements in each new release of Pandoc that I would dearly like 
> making available to our users as soon as possible.

I can understand that. But by the same reasoning, I’d really like to
have GHC-7.10 in unstable right now. Why do I not upload it? Because
unless we give up on Haskell in Debian stable, getting our packages (and
_all_ of them at the same time) into a releasable state at one is the
biggest issue and usually, unfortunately, the priority.

Note that currently, well over 95% of our packages are in a good shape;
it’s the few odd packages that keep holding up the process. If it were
not for them, I guess we’d have GHC-7.8 in testing already and could
happily attack the next wave of package upgrades.

Maybe aiming for Stackage LTS is indeed too slow, in that case we could
aim to follow Stackage nightlies, which would pick up new upstream
releases much faster, I believe.

> 1.14 packaging work has been pushed to master git branch.  It need arise 
> to make another packaging release of the earlier upstream release, then 
> please ping me about that - I prefer to branch off for that instead of 
> more ugly approaches like reverting or messy merging.

How do you feel about uploading pandoc 1.14 to experimental? Worth the
extra effort? It may or may not be possible depending on how many and
which packages would have to be uploaded to experimental along with it.

Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: