<br><br><div class="gmail_quote">On Sun, Apr 17, 2011 at 10:51 AM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
Am Sonntag, den 17.04.2011, 14:37 -0300 schrieb Felipe Almeida Lessa:<br>
<div><div></div><div class="h5">> On Sun, Apr 17, 2011 at 12:53 PM, Joachim Breitner<br>
> <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br>
> > work of 1 module in 10 packages. The new OpenGL packages have split out<br>
> > lots of small packages (OpenGLRaw, StateVar, Tensor, ObjectName). Please<br>
> > review this and see if you can somehow lessen the package number<br>
> > inflation before your version enters the platform.<br>
><br>
> At least StateVar is very useful outside OpenGL.<br>
<br>
</div></div>I’m not saying it is not useful. But there is very little code and most<br>
of it is rather, well, trivial. So if you need the functionality in one<br>
of your packages only, then you can put it there. If you need it in on<br>
collection of multiple packages with one package dominating the<br>
dependency tree, then put it there.<br>
<br>
A package of its own for these few lines is only required if<br>
* Package A and package B provide an _interface_ in terms of StateVar<br>
* Neither A depends on B nor B depends on A<br>
* There will be a package C that not only uses the interface of both A<br>
and B but also combines them, e.g. really requires that the same type is<br>
used in both the interfaces.<br>
<br>
Also, small packages without external dependencies can be combined in<br>
one package without much loss. E.g. a package opengl-utils (or some<br>
better name) that provides all of StateVar, Tensor, ObjectName would do<br>
the job equally well.<br>
<br>
I know that its tempting to have very fine-grained Cabal packages,<br>
because its so cheap to put them on Hackage and leave it to<br>
cabal-install to install take care of them. Unfortunately, it doesn’t<br>
scale on the Distribution side very well – and we are already trying<br>
hard to keep the per-package maintenance cost down.<br></blockquote><div><br></div><div>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 :)</div>
<div><br></div><div>Thanks for your input!</div><div>Jason</div></div>