Dear Giovanni,
Am Mittwoch, den 23.03.2011, 10:25 +0100 schrieb Giovanni Mascellani:
> On 23/03/2011 07:33, Joachim Breitner wrote:
> > Hi,
> >
> > Am Samstag, den 19.03.2011, 10:15 +0530 schrieb Joachim Breitner:
> >> Am Freitag, den 18.03.2011, 09:34 +0530 schrieb Joachim Breitner:
> >>> None of the outstanding issues on
> >>> http://wiki.debian.org/Haskell/CollabMaint/GHC could as well be done in
> >>> unstable, assuming the build failure is really related to dash in
> >>> experimental (which is highly likely).
> >>
> >> actually, not true. I added the issue of the haddock interface version
> >> (http://lists.debian.org/debian-haskell/2011/03/msg00049.html), which
> >> should be implemented in experimental first.
> >
> > I started to work on it, and at least ghc-doc now depends on haddock via
> > a virtual package haddock-interface-<n>.
>
> I was reading again the original problem description again: we're doing
> these things just to have a binNMU-able ghc, aren't we? Wouldn't it be
> better, instead of making a complicated mess with lots of dependencies,
> try to understand how we can include a dependency of this type:
>
>[..]
>
> I don't think this would be difficult to implement in d/rules, as
> another substvar that is used in d/control. And it seems to solve the
> same problem. I can try to implement it, if you're ok with it.
as I implemented the above already, I don’t think its required any more.
And my solution was actually quite small and straight forward.
Also, your solution does not work for haskell libraries. Assume we want
to guarantee that all installed doc packages have an haddock index
readable by the installed haddock (this has to be discussed yet), so we
add a dependency of -doc to haddock. With your scheme, if a new ghc
point release is uploaded, this dependency would break and we’d need to
sourcefully upload all library packages.
With my scheme, it would not break if the haddock interface stays the
same (likely for point releases of the compiler). Only if it does change
we’ll have to do sourceful uploads, but these are not avoidable anyways.
But your scheme might be useful in other situations; you could suggest
it to the dpkg maintainers to provide it generally, e.g. a substvar
${binary:NMUVersionRange} next to ${binary:Version}.
Greetings
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part