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

Re: Bug#504528: libghc6-configfile-dev: Fails to configure: MissingH-1.0.1 doesn't exist



Hi,

Am Mittwoch, den 19.11.2008, 11:22 -0600 schrieb John Goerzen:
> 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.

The ghc-pkg identifier for your package contains all four digits.
Doesn’t that mean that if you upload 1.0.2.2 (even with an compatible
ABI), that then depending packages will break in postinst due to ghc-pkg
complaining?

If not, it will be hard to automatically guess which part of the version
is API-dependent and which are Debian revisions. I think it’d be
possible to still use the 1.2.3-4 scheme with a native package (ignoring
the lintian warning).

A different approach, but one that should be coordinated with the
ghc-6.10 upload, could be this:

In the new ghc version, I have read that ghc uses some hashes of the
interfaces per package to track compatibility (e.g. if a dependency
library is updated, ghc will warn or throw errors when you try to use
the depending library). If now every library would Provide: a virtual
package indicating the haskell package name and version (as known to
ghc-pkg) and this interface hash, then this could be used to depend
upon. I’m not sure if it’s worth the trouble (and risk of new bugs)
though, depending on the specific (upstream or upstream+debian, not sure
what’s best) version should be fine.

> > 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.

I see your worries. I didn’t get this impression from the pkg-perl team,
but maybe it’s just an positive exception :-)

Also note the big principal difference between, say pkg-perl and
pkg-games: The former handles exactly one case of homogenious packages
which are handled the same way, with the explicit goal to make it less
work to package new libraries (and versions thereof) by providing tools
and infrastructure, the latter shares work out of common interest, with
little chance for synergy effects.

Having a packaging team is not a necessary condition for consolidation,
and by no means every package _has_ to be maintained by it. But at least
we need to have an consensus between the maintainers of haskell library
packages, so we get the benefit of one and only one way to build haskell
packages. Currently, it’s

$ grep-available -n -e -P 'libghc6-.*dev' -s Maintainer|sort | uniq -c
      6 Arjan Oosting <arjan@debian.org>
      1 Chris Lamb <chris@chris-lamb.co.uk>
      1 Florian Ragwitz <rafl@debianforum.de>
      2 Florian Ragwitz <rafl@debian.org>
     16 Ian Lynagh (wibble) <igloo@debian.org>
      1 Isaac Jones <ijones@debian.org>
      3 Joachim Breitner <nomeata@debian.org>
      2 John Goerzen <jgoerzen@complete.org>
      9 Kari Pahula <kaol@debian.org>
      2 Liyang HU <debian.org@liyang.hu>
     12 Marco Túlio Gontijo e Silva <marcot@riseup.net>
      2 Víctor Pérez Pereira <vperez@debianvenezuela.org>

Especially kaol’s opinion is important here, being the new ghc
maintainer, and Arjan, as the current maintainer of haskell-devscripts.


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: Dies ist ein digital signierter Nachrichtenteil


Reply to: