Hello,
I have a first cut of a template for cabalizing and debianizing haskell libraries. Do a,
darcs get http://www.n-heptane.com/nhlab/repos/cabalDebianTemplate
...and see the terse instructions in INSTRUCTIONS.txt. The instructions assume you already know the basics of cabal and debian.
I have used the template to debianize or cabalize+debianize a few third party libraries for local use, and it only takes 1-2 mins. Of course, for local use I don't bother to update all the descriptions in debian/control, etc.
This version does not generate profiling libraries -- so if we decide that it should, I will add that.
My current plan is something like this:
(1) Get a template hammered out that everyone likes (profiling, etc) (2) Write some newbie friendly documentation for it (3) Publish the docs on the wiki (4) Write an script to automate the template->specific package conversion process.
It is possible that (4) may get moved between (1) and (2) depending on how difficult and desirable it is.
If you have any suggestions or improvements let me know.
j.
Op di, 30-05-2006 te 12:05 -0700, schreef Jeremy Shaw:
Hello,
I have a first cut of a template for cabalizing and debianizing haskell libraries. Do a,
darcs get http://www.n-heptane.com/nhlab/repos/cabalDebianTemplate
...and see the terse instructions in INSTRUCTIONS.txt. The instructions assume you already know the basics of cabal and debian.
I have used the template to debianize or cabalize+debianize a few third party libraries for local use, and it only takes 1-2 mins. Of course, for local use I don't bother to update all the descriptions in debian/control, etc.
This version does not generate profiling libraries -- so if we decide that it should, I will add that.
My current plan is something like this:
(1) Get a template hammered out that everyone likes (profiling, etc) (2) Write some newbie friendly documentation for it (3) Publish the docs on the wiki (4) Write an script to automate the template->specific package conversion process.
It is possible that (4) may get moved between (1) and (2) depending on how difficult and desirable it is.
If you have any suggestions or improvements let me know.
Well if a package would be based on this files with only the changes made were based on the instructions in the instruction file, I would not upload it to the Debian archive (if I were a DD), and from what I have seen on debian-mentors it isn't enough for sponsoring either.
Some points:
debian/control: * duplicate build-dependencies: debhelper, ghc6 and haskell-devscripts should not be Build-Depends-Indep
debian/rules: * drop the CFLAGS we don't build C libraries but Haskell packages, * drop DEB_HOST_GNU_TYPE and DEB_BUILD_GNU_TYPE as we don't call ./configure with these variables * drop the INSTALL_PROGRAM cruft, this is deprecated by dh_strip. * drop the configure target * don't use hyphens at the beginning of a command to ignore errors, for instance replace -./setup clean with if [ -x setup ] && [ -e .setup-config ] ; then ./setup clean ; fi * drop the unnecessary dh_FOO calls and commented out dh_FOO calls
You might want to look at the changes I made for the haskell-crypto [1] and haskell-newbinary [2] packages (I am not the maintainer, so he might not agree with all my changes) to see my ideas for the control and rules file.
[1] dget http://moonshine.dnsalias.org/debian/unstable/haskell-newbinary_0.0.20051211... [2] dget http://moonshine.dnsalias.org/debian/unstable/haskell-crypto_2.0.3-4.2_i386....
Finally packages which are intended to be uploaded to Debian should not be native packages but be cleanly split in a orig.tar.gz and a diff.gz and don't include the _darcs directory.
Just my 2cents
Greetings Arjan
On Tue, May 30, 2006 at 12:05:44PM -0700, Jeremy Shaw wrote:
I have a first cut of a template for cabalizing and debianizing haskell libraries.
I haven't had a good look, but I note you use dh_haskell. Personally I don't see the attraction of dh_haskell over update-haskell-control. The latter can be used to keep build-deps in sync as well as deps (and the fact that dh_haskell looks like it still incorrectly generates deps like ghc6 (<< 6.4.1-999) at least 7 months after I first talked about it with John doesn't help endear it to me either; correct info is in /usr/lib/haskell-utils/${impl}_vars and can be augmented if wanted) and will hopefully in the future make it easy to also generate build-deps and deps for Haskell libraries by parsing the .cabal file.
If policy is changed so that we don't want to strictly depend on compiler/library versions then using both might make sense, one to get Haskell implementation arch info and Haskell libraries needed for the build-deps and the other to generate the appropriate deps at build-time.
My personal opinion is that policy is right, however, as we will want to make sure everything is built against up-to-date libraries/compilers everywhere (both for bug-fixing reasons and so migrations to testing can happen), and with the low version turnover and flat dependency tree we have I think this way will be less effort overall.
If I'm missing some other way in which dh_haskell would make my life easier, please do enlighten me :-)
Thanks Ian
On Mon, Jun 05, 2006 at 12:57:20AM +0100, Ian Lynagh wrote:
On Tue, May 30, 2006 at 12:05:44PM -0700, Jeremy Shaw wrote:
I have a first cut of a template for cabalizing and debianizing haskell libraries.
I haven't had a good look, but I note you use dh_haskell. Personally I don't see the attraction of dh_haskell over update-haskell-control. The latter can be used to keep build-deps in sync as well as deps (and the fact that dh_haskell looks like it still incorrectly generates deps like ghc6 (<< 6.4.1-999) at least 7 months after I first talked about it with
That's because I still don't understand why your suggestion is better. But I'm sitting in a train station right now, and will have to look at this more when I get back home.
-- John
On Sun, Jun 04, 2006 at 07:12:02PM -0500, John Goerzen wrote:
On Mon, Jun 05, 2006 at 12:57:20AM +0100, Ian Lynagh wrote:
On Tue, May 30, 2006 at 12:05:44PM -0700, Jeremy Shaw wrote:
I have a first cut of a template for cabalizing and debianizing haskell libraries.
I haven't had a good look, but I note you use dh_haskell. Personally I don't see the attraction of dh_haskell over update-haskell-control. The latter can be used to keep build-deps in sync as well as deps (and the fact that dh_haskell looks like it still incorrectly generates deps like ghc6 (<< 6.4.1-999) at least 7 months after I first talked about it with
That's because I still don't understand why your suggestion is better. But I'm sitting in a train station right now, and will have to look at this more when I get back home.
Two reasons: * The info comes from the compiler packager * It doesn't break should ghc6 6.4.1-1000 be released.
I thought I'd convinced you in http://meme.b9.com/cview.html?channel=haskell&date=050816 (search for 999), but if you still disagree then please let me know.
Thanks Ian
At Mon, 5 Jun 2006 00:57:20 +0100, Ian Lynagh wrote:
On Tue, May 30, 2006 at 12:05:44PM -0700, Jeremy Shaw wrote:
I have a first cut of a template for cabalizing and debianizing haskell libraries.
I haven't had a good look, but I note you use dh_haskell. Personally I don't see the attraction of dh_haskell over update-haskell-control.
Is there a good place to get moqre information on using update-haskell-control? dh_haskell provides a number of features that I do not see present in update-haskell-control -- but I could be missing something.
A package built around dh_haskell typically has a very simple and generic debian/rules file (see the cabalDebianTemplate for an example). You then add the appropriate paragraphs to debian/control and dh_haskell automatically figures out how to build all the appropriate .debs. So, in this sense, it is fairly similar to cabal where you have a generic Setup.hs and you control it by putting different data in the .cabal file.
The other thing dh_haskell does is update the haskell variables in the debian/control file. I believe this is the area where dh_haskell and update-haskell-control overlap? I think I could use both dh_haskell for debian/rules, and update-haskell-control for debian/control -- but it would be nice to have one tool that "Does It All".
Thanks! j.
debian-haskell@lists.urchin.earth.li
-
Arjan Oosting -
Ian Lynagh -
Jeremy Shaw -
John Goerzen