On Tuesday 05 October 2004 6:40 pm, Isaac Jones wrote:

On Tue, 05 Oct 2004 13:08:42 -0500, John Goerzen

jgoerzen@complete.org wrote:

...

Package: wnpp Severity: wishlist

• Package name : haskell-cabal

I think I would prefer to maintain this package, if you don't mind.

No problem. I just wanted to make sure it is in sid.

I have made uploads already for the source package that generates a binary package for ghc6. I have added all the hooks necessary for it to build ghc5 and also fixed some places in the source where it was incompatible with ghc5, but there is a bug relating to subdirectories in the ./setup build support for ghc5 that prevents that build from working. Also, I fixed postinst and prerm, modified the packages to put the libraries in the locations mandated by the Debian haskell policy (or as close as possible, at least), modified the build-deps and deps for same, added copyright text, etc.

nhc98 support should also be fairly easily added, and Hugs too if the source is compatible with it.

So let me know when you want to take it over. If the answer is "now", please contact me for my diff.gz. (Actually, you'll probably want it anyway, since you probably want to commit those ghc5 fixes to your source tree at least). But I've got some more Debian stuff to contribute yet. If you (or someone) can fix the ghc5 issue, then we'll get at least a ghc5 lib out of it.

I'm not sure it's ready to enter Debian yet... the interface isn't finalized, so I'd like to keep it out of testing.

So far, it is likely to be used only as a Build-Dep in Debian, which means it's an internal problem for us to sort out (not bothering end users).

But if it is kept out of testing, then there goes MissingH, Hunit, and HSQL -- unless those are all converted to using something else like hmake, which seems like a waste of time since the world is standardizing on Cabal.

Interfaces have changed before. We can handle it.

BTW, there's a tool for creating a skeleton Debian package from a cabal-ized package. See debianTemplate and dh_make.

I saw that, though my .debs aren't building with it yet. I'm concerned that some of the files it is using (especially postinst/prerm) are buggy. I also wanted to wait until I have a generic infrastructure for building a library with all four compilers/interpreters in Debian first, then patch the template to support that.

I'm close, but haven't tested it yet since I don't yet have any code that actually builds with all four compilers/interpreters in Debian...

But I hope to have that all done in a day or two, time permitting.

-- John

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

On Wednesday 06 October 2004 09:37 am, Ian Lynagh wrote:

[dropped the cabal ITP bug from CC list]

...

-- 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,

Shouldn't cabal do that for you?

I don't think so.

First, you'd have to use Perl. (Yes, I know, icky language.) You probably don't want to make Cabal a dual-language package. The debhelper lib is Perl-only, and you need to use it to find out things such as exactly what packages are being built, and to actually put the stuff in the scripts at the right place.

Secondly, this represents a very tight coupling with the Debian build system -- probably more than is appropriate for a non-Debian-specific tool. I think the Debian build scripts should be calling Cabal to do things, not the other way around.

...

plus getting the deps exactly right

Which deps?

From libs to compilers. (There are no manual deps for Haskell binary packages that are not libraries; build-deps only.)

The compiler ones want information from the compiler packages to be done properly, and this isn't going to happen until either the latest ghc6 gets built on sparc and goes into testing or I get bored and upload a new version anyway. I'll probably add the scripts to put

But we can already see what is on the build system and generate a substvars file for it. So in my control file for, say, libghc6-missingh-dev, I can say:

Depends: ${ghc6:Depends}

And it could expand to:

Depends: ghc6 (>= 6.2.1), ghc6 (<< 6.2.2)

Just by seeing that I have 6.2.1-5 installed on my system. Once the compilers provide the appropriate file, it can use it.

You have to modify control somehow. Why not make it easy?

Also, I think you would need to check with the debhelper people before adding dh_* packages/binaries.

Nope, debhelper is modular. All dh_* bins are in /usr/bin. It's no problem to add a new one, and it doesn't mess up debhelper at all.

Scripts for postinst/postrm live in /usr/share/debhelper/autoscripts, and again a haskell-devscripts can just add files there.

...

• cabal-buildhelper to automate building libraries for up to the

four supported Haskell environments in Debian

I'm not sure how much of this the cabal guys have done. Isaac, Marvin?

From the code I've seen, none.

The basic pseudo code is:

foreach TARGET in ghc5 ghc6 nhc hugs: ./setup clean ./setup configure --with-hc-compiler=$TARGET --prefix=foo ./setup build ./setup install --instprefix=foo cp .*config* wherever configure ghc-pkg/whatever in postinst/prerm

Of course, Cabal doesn't yet actually work with nhc/hmake or ghc5 (haven't tested hugs) so we can't do much just yet.

But here's what I'm planning:

A tool can learn from debhelper (which in turn learns from control) exactly what packages are being built. From that, it can infer what targets need to be built. It can do the cabalized build for each target automatically, installing each at the appropriate spot.

During the binary-arch target in debian/rules, another tool can set up the appropriate postinst/prerm scripts automatically. It can learn from Cabal the package name and thus infer where it's installed and the location of the appropriate pkg file.

Essentially we will have the building of all possible compiler packages for a given library down to three commands in debian/rules and one clause per package in debian/control, with almost everything else handled automatically.

*That's* what I'm waiting for before making dh_make templates. What we have now is fragile and manual. When someone dh_make's a Haskell library, all he has to do is fill in the package name, description, and copyright, and everything else should Just Work for all 4 supported environments.

-- John