Hi, Am Mittwoch, den 09.12.2015, 21:50 +0100 schrieb Andreas Tille: > The target package I was talking about is actually not a library (at > least what *I* would call library - no idea about Haskell terms > here). > [..] > As far as I know there is no specific interest and I would like to > keep things as simple as possible to get the final user application. Ok. If it is just a binary, things are less complicated. (Reason being: due to static linking of Haskell executables they do not block testing transitions etc.). In that case, I suggest you keep the package under your maintenance, I’ll help you with the initial packaging, and then we’ll be available to help you if you have problems with it. > > For hackage packages, this is often a sign of insufficent upstream > > activity, which can cause the package to cause problems for us, and > > eventually a swift removal. Are you sure this is an actively maintained > > project? > > I'm sure that you as developers are talking about a different scale of > "active maintenance". The package is used as is by biologists and works > successful in the target environment. It might happen that it does not > work with the latest and greatest Haskell compilers. I would assume > that upstream is interested in updating but I can not answer your > question reliably. In other programming languages I was always able to > keep the code up to date with the help of other Debian people in case > upstream was not as responsive as hoped but there are also very active > and interested upstreams. I would assume that if an upstream is > choosing a *very* unusual language for this field at will be an engaged > developer. :-) We can give it a shot, but notice that I’d rather drop a leaf package than invest too much time in it, in case it holds up a upgrading the rest of Haskell. > > If so, we’d have a lot less to worry if it were part of stackage > > (which, in a way, is a Distribution-independent distribution of Haskell > > package). I suggest you contact the author and talk him into adding his > > package to stackage, which is easy and provides free QA to him: > > http://www.stackage.org/authors > > I can do so but top fully understand this strategy: Is it true that I > would then point the d/watch file to stackage.org? No, it does not necessarily affect the packaging. The point of the strategy that if a package that is part of stackage gets out of date, e.g. in the version of its dependencies that it allows, the stackage guys notice that earlier and sort it out with the maintainer, so we don’t have to. > > > I'm also aware that libghc-hierarchical-clustering-* is not even > > > available in unstable but cabal-debian has added this to the > > > Build-Depends. I guess I need to package this as well. > > > > Right; or even better, the DHG has to. That package looks more > > actively > > maintained, but should also enter stackage before it gets into > > Debian. > > OK, I'll talk to upstream. Thanks! Feel free to CC me (@nomeata) on any github issues you might create in the process. I tried to add both the packages to the package plan¹, and it shows the first problem: phybin depends on text>=0.11 && <0.12, when we already have text 1.2. That the a typical symptom of a package that does not keep up with the rest of the ecosystem. It very likely is just a matter of patching the dependency range in the .cabal file, but in general, it is not viable for us to do that for 700 packages... I suggest you notify upstream about this problem and see if he cares enough to do such minor maintenance tasks. It’s a prerequisite to get added to stackage as well. hierarchical-clustering seems to be compatible with everything we have right now. Greetings, Joachim ¹ see http://anonscm.debian.org/cgit/pkg-haskell/package-plan.git/ and http://anonscm.debian.org/cgit/pkg-haskell/package-plan.git/plain/README.md -- 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