Joachim Breitner wrote: > > But sometimes I feel like I'm navigating > > around holes in the packages available in Debian. > > That’s expected. We (well, I) don’t think its useful to package > everything from hackage indiscriminately. > > It’s hard to tell whats genera-purpose and good. And given that haskell > packags are not that cheap to package (e.g. in terms of buildd work – > every update of a dependency results in rebuilds of all depending and > indirectly depending packages) we should pick only useful ones. > > But I consider a package as useful if some developer or user puts in the > effort to ask us to package these, especially if required for a program > that is included in Debian. So I guess we can include these packages in > the next round of updated. FWIW, I realized another one I could have used is the graphviz package. I wrote my own, crappy 60 line interface to dot, but it has a much nicer and presumably less buggy interface. > Do you need them asap or can it wait for after the ghc7 transitions > (which is waiting for ghc7 to pass through NEW – this is taking really > long, maybe we should ping ftp-master, after all the package is not > really NEW, just renamed – then testing it a bit in experimental and > then doing the uploads to unstable)? All of these are things that I've already worked around not having in my code, so I don't need any of them urgently. Using any of them will make my code simpler, and I think they're some pretty generic building blocks that are likely to be used by others. To some extent, demand-based packaging works. But actually, it may work better for the perl team than the haskell team, since there are lots more existing perl programs using CPAN libraries. My concern with only packaging haskell libraries on demand is that it may create a bootstrapping problem. -- see shy jo
Attachment:
signature.asc
Description: Digital signature