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

Re: Long term goal: Multiple cabal packages per source package



Joachim Breitner wrote:

> if you have followed the recent discussion on the Haskell library and
> cafe list, you might have noticed that there is a reluctancy in the
> Haskell community to stop creating packages for tiny fragments of code.
> Eventually, this will not scale any more for us.
> 
> The solution that we could work towards (after the migration, the
> earliest) is to bundle related Cabal packages into one source package,
> but still create multiple binary package. The rought roadmap would be
>  * Use the dpkg quilt 3.0 multi upstream tarball feature.
>  * As there is no standard: Think about how to store the list of 
>    versions of the bundled tarballs in the source package, e.g. 
>    debian/source/versions.
>  * Wait for bugs.debian.org/531321 to be fixed or replace our use of 
>    uscan --download by, say, debian/rules get-orig-tarball
>  * Modify haskell-devscript to be able to build more than one Cabal 
>    package, even when one depends on the other (Is doable, after all
>    the ghc package does it).
>  * Either hard-code the order of building or, better, include some code
>    that figures it out.

+1
 
> I see uses for it for example for the Haskell-Platform, for the hxt
> series of packages, for the leksah packages, for the gtk2hs package, for
> the various sets of database packages – basically for every set of
> packages that are usually updated in lockstep anyways.

I just recently built personal debian packages for everything required
by wai, warp and http-enumerator. Ended up being some 12 or 15 packages.
The thoughts of doing proper debian packages for that lot was scary.

I currently have a script and some Makefile foo that allows me to specify
a hackage library and version and it will build a package. Obviously
the package is not good enough to go straight into Debian, but it does
a large chunk of the grunt work (although it doesn't figure out dependencies
yet). I've been thinking of extending and improving this to make it a
real debian tool for managing packages on Debian.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/


Reply to: