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

Bug#275069: [Debian-haskell] Bug#275069: ITP: haskell-cabal -- Haskell Common Architecture for Building Applications and Libraries



On Tuesday 05 October 2004 11:24 pm, Isaac Jones wrote:
> > I have made uploads already for the source package that generates a
> > binary package for ghc6.
>
> Are you saying you already uploaded it to sid?

Yup, plus MissingH, which uses it, and I'm planning to get another 
package -- maybe haskell-devscripts or something along those lines -- 
in the next few days.  I plan to have, in this package, things like:

 * dh_haskell to automate putting the appropriate package 
register/unregister calls in postinst and prerm, plus getting the deps 
exactly right

 * cabal-buildhelper to automate building libraries for up to the four 
supported Haskell environments in Debian

I expect this to use the Cabal API for part of what it does, though I 
haven't yet investigated the API.

> Can you please send me patches via darcs?  Brief instructions for

I'll look into that and maybe do that by Friday; for now, here's my 
current diff.gz.  I've just recently learned tla so the thought of 
learning Yet Another VC System isn't the most appealing at the 
moment :-)

> It's going to slow development of Cabal of I have to worry about
> breaking packages in testing. I definitely want things like HUnit and

You don't.  Testing packages are OK if they are built with what is in 
testing.

Incidentally, I don't see any packages on the horizon that contain a 
Setup.lhs that is anything but the one line call into Simple.  Except 
mine, which is My Problem if Cabal changes.  I've received fair warning 
that it might, so I will not gripe if that happens :-)

Really, this is not a new problem.  If you change the API and it breaks 
building new versions of stuff already in testing (which is what we're 
talking about here -- *building*, not *running*), then the maintainers 
of those packages have to fix the build systems.  Which they will.  
This has happened before and it will happen again.  It's not a new, or 
particularly hard, problem.  And it is not *your* problem, it's the 
problem of people that *use* Cabal.  That set of people, at the moment, 
consists of -- me.  And I have committed to dealing with any changes 
that you might make.  So you have no less freedom than you did before, 
and and griping that happens gets directed to me.

See?  Life is good :-)

Just to reiterate -- I highly doubt that there will be any packages in 
sarge that use Cabal for anything but building .debs.  I don't think 
anybody except Haskell developers or porters will have it installed on 
their systems in the Sarge timeframe.  Already-built packages would, of 
course, not be effected by a change in Cabal since they wouldn't link 
in any Cabal code in the build packages.

> WASH to make it into testing, but the best way to do that, IMO, is to
> speed up Cabal development, and I very much appreciate your efforts
> there.  There's a TODO list in the source if you want to know our
> priorities.

I looked, but didn't find it (I'm using the tarball drop on the website, 
btw)

> It might also be good for someone on the Cabal team to be a
> comaintainer on packages that depend on it, so when we break the
> compatibility layer, we can upload Cabal and dependencies at the same
> time.

I'm not quite sure what you mean about "container"...

Anyway, there is no need to do what you're talking about, since we're 
talking about Build-Depends and not Depends here.  That is, a new Cabal 
will not break existing .debs.  It *may* break existing source 
packages, but people will discover that pretty quickly when they build 
their packages again...  Granted, a heads-up would be nice, but that 
level of synchronization isn't necessary.

> Thanks a lot for your work.  I'm excited to see Cabal more widely

Ditto -- Cabal looks like a nice system with a lot of promise.  A little 
Googling will show you that I have frequently complained about such a 
tool for OCaml, and we don't even have compiler diversity there :-)

> And if you haven't played with darcs yet, check it out.  I think
> you'll appreciate how natural it is to send patches.

Will do in a couple of days.

FWIW, most of my Debian packages -- including all of my recent work -- 
are available in Arch/tla repositories at http://arch.debian.org/.  If 
you care to translate Arch patches to darcs ones, feel free :-)

-- John



Reply to: