Hi, Am Montag, den 18.04.2011, 09:39 +0200 schrieb Henning Thielemann:

Joachim Breitner schrieb:

...

Am Sonntag, den 17.04.2011, 12:39 -0700 schrieb Jason Dagit:

...

In this specific case, I'll do what I can to clean things up but your request makes me pause and think that the debian packaging for cabal packages is not automated enough. As haskell developers it seems a little odd to me that we need to consider the cost of creating new packages for the sake of debian. I like debian, so please don't take that the wrong way :)

the observation is correct, but unfortunately hard to change – Debian is large, slow moving, and unlikely to change policies for a corner-case such as Haskell libraries.

As a user I had the impression that the packages become more and more divided into smaller packages (like TeX) and I found this useful, since I only need space for the functionality that I really use.

I have doubts that there is a relevant saving of space when putting this code in a package of its own: ======snip======== module Data.ObjectName ( ObjectName(..) ) where -- | An 'ObjectName' is an explicitly handled identifier for API objects, e.g. a -- texture object name in OpenGL or a buffer object name in OpenAL. class ObjectName a where -- | Generate a given number of object names, which are guaranteed to be -- unused. By generating the names, they become used. genObjectNames :: Int -> IO [a] -- | Make the given object names available again, declaring them as unused. deleteObjectNames:: [a] -> IO () -- | Test if the given object name is currently in use, i.e. test if it has -- been generated, but not been deleted so far. isObjectName :: a -> IO Bool ======snip======== considering that there is a license file, a .cabal file, it will create separate haddock data with an index.html, an alphabetical index, it will have an entry of its own in the package file, you will have to look at the package name when upgrading, more dependencies that cabal-install needs to think about... And with TeX, at least here, all the small .sty packages are then distributed as one big thing called texlive (split into large sets such that “humanities“, “science”, “publishing”), probably because it is too tedious to individually package and select what package I really want. If the trend to micro-package continues on Hackage, maybe that is what will happening: Someone will create collections of packages, similar to the plaform, maybe one for graphics (containing opengl, gtk2hs, etc.), one for audio. And then distributors would have packages corresponding to those bundles. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de

Hi, Am Montag, den 18.04.2011, 07:06 -0300 schrieb Felipe Almeida Lessa:

On Mon, Apr 18, 2011 at 4:30 AM, Joachim Breitner wrote:

...

Also, the policies that make life a bit more harder for us are also the policies that make Debian a good distribution: E.g. manually creating a copyright file describing who all has copyright on the files, and what license the files are under – .cabal has fields for that, but unfortunately, they very often do not reflect the reality of the .hs files. Or the other one, requiring that an upload of a source package is accompanied by a manually built and signed binary package ensures that the maintainer actually checked that the package builds and hopefully has tested it.

Is it a good solution to have a Debian package containing many Cabal packages? For example, 'opengl-utils' with all OpenGL-related packages? Maybe this could be a good compromise.

it’s something that I have in mind to resort to eventually, but our tools currently assume one cabal package per Debian package – but nothing that cannot be fixed. 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