Re: Bug#504528: libghc6-configfile-dev: Fails to configure: MissingH-1.0.1 doesn't exist
Joachim Breitner wrote:
> Hi,
>
> Am Mittwoch, den 19.11.2008, 11:15 +0100 schrieb Philipp Kern:
>> Hi John,
>>
>> On Tue, Nov 11, 2008 at 09:51:01PM +0100, Stefan Potyra wrote:
>>> simply rebuilding will make the maintainer scripts pickup the newer
>>> missingh dependency, and hence will fix this bug.
>>> However I haven't tested yet if haskell-configfile will still be
>>> functional with the later missingh (though doubt it isn't).
>> adding calls to dh_haskell_depends would prevent further bug reports
>> of this kind. It looks like it fixes the problem also in this case
>> properly (i.e. adding sensible binary dependencies). Would you mind
>> to add such calls to your debian/rules or look into adding it
>> to dh_haskell?
>
> hmm, another case of haskell packages braking our buildd infrastructure.
> We really need get this fixed.
That is true. I'm looking at dh_haskell_depends right now. In
libghc6-configfile-dev, it's inserting this:
Depends: ghc6 (>= 6.8.2-7), ghc6 (<< 6.8.2+), libghc6-missingh-dev (>=
1.0.2.1), libghc6-missingh-dev (<< 1.0.2.1+), libghc6-mtl-dev (>=
1.1.0.0-2), libghc6-mtl-dev (<< 1.1.0.0+), libghc6-parsec-dev (>=
2.1.0.0-2), libghc6-parsec-dev (<< 2.1.0.0+)
Now, libghc6-missingh-dev is a Debian native package, since I am
upstream on that as well. I use x.y.z for the upstream version number,
and the last component for the Debian version number. Debian version
numbers do not imply API changes, cabal version number changes, or the
need for recompilation. On packages like libghc6-parsec-dev it seems to
be doing the right thing regarding not causing a broken dep when the
Debian version number increments. I'm not sure what the right thing
with a Debian-native package is here, but it's going to cause a lot of
hassle as it is.
> John, you haven’t yet commented on the idea of a Haskell Packaging Group
> similar to pkg-perl which could handle all the uniform haskell library
> packages we have (not including haskell binaries). What do you think of
> that?
In all honesty, I have not been involved with pkg-perl specifically, but
I have generally not liked the approach of the pkg-* groups. They tend
to move slowly, don't get new libraries into sid very quickly, and seem
to want all development to occur in some sort of annoying svn repo that
they're heavy-handed about handing out commit access to.
I think that there are much nicer ways to go to make life easier in Debian:
1) Start with the toolset consolidation as you have mentioned.
2) Add on top of that the automatic Cabal-to-Debian work that's been
floating around recently
3) This should result in a pretty nice build system.
At that point, the time would be ripe to evaluate the need for such a group.
-- John
Reply to: