Because I very much want cl-launch to be more widely used, I've packaged it for debian myself. I'd upload it or whatever, if only I knew how to do that. This is my first attempt at building a debian package, so please tell me what I did wrong, if anything. The URL with everything is http://fare.tunes.org/files/debian/ [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Brevity is the soul of wit. -- Shakespeare
On 18.09.05, Faré wrote: Hello Faré,
Because I very much want cl-launch to be more widely used, I've packaged it for debian myself. I'd upload it or whatever, if only I knew how to do that.
You can not do that for yourself. You'll have to get an existing Debian developer to upload it for you.
This is my first attempt at building a debian package, so please tell me what I did wrong, if anything.
Please make use of our package checkers: linda and lintian, this will tell you about some problems with your package. lintian -i cl-launch....changes Especially the native-package-with-dash-version warning is important. Having the original source code and the debian modifications seperated makes it easier for other people to fix bugs. (more info is in the lintian output) Okay, I've found some things that lintian did not find: - your copyright file, that now contains the LLGPL preable to the LGPL, should also contain a pointer to /usr/share/common-licenses/LGPL - you have an preinst script in your debian/ directory that does not take any action, remove it - your postinst script registers something to the common lisp controller. However, there is nothing to register. Also, if you really meant to register something in the postinst script, you should unregister it in your prerm script, which is not done currently. - your postinst script installs /usr/share/common-lisp/cl-launch ... better generate these things at package build time to have them included in the deb file. Install them by means of debian/rules Otherwise, these files will not be under dpkg's control and other packages could easily overwrite them. I see no reason in generating these files at postinst stage rather than build time - the watch file, as it is currently, is useless. try "uscan --verbose" in your source directory to test it and "man uscan" - your postinst script calls register-common-lisp-source, but your package only Recommends: the common-lisp-controller. But just don't call the CLC, there is nothing to register So you see, I just got rid of all your pre- and post- -inst and -rm scripts. ;-) You could also call dh_lisp (Build-Depends on dh-lisp) as the last thing in your install: target of debian/rules You can also put files to install in debian/install with lines like source usr/bin/dest instead of calling dh_install -i every time. Same goes for debian/manpages instead of dh_installman, debian/dirs instead of dh_installdirs, and so on. That's just an advise, no mistake. :-) (more info is in the manpages of the dh_ tools) Your package is completely architecture independent, you should not need a Build-Depends: line in your control file, only Build-Depends-Indep: You might get useful information in the packages maint-guide, developers-referenec and debian-policy Regards, René
Dear René, thanks a lot for reviewing my package. I made a new attempt. Here are comments for some things you said I'm not sure what to do about:
lintian -i cl-launch....changes Especially the native-package-with-dash-version warning is important.
Am I not the one making the debian package?
- your postinst script installs /usr/share/common-lisp/cl-launch ... better generate these things at package build time to have them included in the deb file.
Wouldn't that make the package unnecessarily bloated? The files are just excerpts of the main script. There's about zero chance of someone accidentally stepping on them.
Otherwise, these files will not be under dpkg's control and other packages could easily overwrite them.
Could I register the files to dpkg in postinst? Oh and if there's a md5sum, I should register the new sum for /usr/bin/cl-launch, too.
I see no reason in generating these files at postinst stage rather than build time The only reason I see is keeping the package lean. Just because debian is bloated doesn't mean I have to contribute to that.
- the watch file, as it is currently, is useless. try "uscan --verbose" in your source directory to test it and "man uscan"
uscan looks much too clever to me. The "source package" is a single file on CVS. How am I to check that the CVS revision has been bumped up? And what if the latest CVS is not stable? Do I even need such a file? I mean, I'm the first to know when I make a modification to cl-launch...
You could also call dh_lisp (Build-Depends on dh-lisp) as the last thing in your install: target of debian/rules Do I need dh_lisp? cl-launch doesn't need a lisp implementation. It can produce files that run require a lisp implementation (on the foreign platform where they will be run).
PS: now that I rethink of it, maybe the helper files I install should go to /usr/share/common-lisp/source/cl-launch and not /usr/share/common-lisp/cl-launch since they are actually source code (one .lisp and one .sh file). Actually, maybe it'd be better if cl-launch was part of the common-lisp-controller package, and its lisp header was included after post-sysdef-install.lisp or in place of it -- /var/cache/c-l-c/$USERNAME/ is an administration issue that could be eschewed if using ~/.cache/lisp-fasl/ instead. Reminds me that a little bit of magic must be done to correctly handle *arguments* after a dump & restore. PS: how do I exclude the CVS crap from the source package? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Floating point numbers are like sandpiles; every time you move one you lose a little sand and pick up a little dirt" -- Vic Vissotsky
On 19.09.05, Faré wrote: Hello Faré,
Especially the native-package-with-dash-version warning is important. Am I not the one making the debian package?
Yes, this are you. The thing is, if you really want to package it Debian-native, you may not use a version like x.y-z, but only x.y. This would require a cl-launch version bump on every change of packaging, not only when the software itself is changed. Debian-native packages are actually for applications that are exclusively made to be packaged for Debian. CL-Launch does not look like one such application for me. (more info is in the developers-reference and debian-policy)
Wouldn't that make the package unnecessarily bloated?
Well, the space is taken on the hard disk of the user anyway. This is mostly an opinion-thing, I think. I prefer having most files under control of dpkg. ;-) For the reasons mentioned below.
Could I register the files to dpkg in postinst? Oh and if there's a md5sum, I should register the new sum for /usr/bin/cl-launch, too.
This has recently been discussed on debian-devel, but I really forgot what the consensus was. At least I am unaware of a possibility to register md5sums and files to dpkg dynamically.
The only reason I see is keeping the package lean. Just because debian is bloated doesn't mean I have to contribute to that.
One other advantage in putting those files into the package is, that one can find out the package that file belongs to using dpkg -S and also find the package using apt-file and packages.debian.org. Creating files through postinst scripts makes them seem unrelated to any package. I think that is not desired if it is avoidable. These advantages imo weigh more than a few kilobytes less of package size.
uscan looks much too clever to me. The "source package" is a single file on CVS. How am I to check that the CVS revision has been bumped up?
uscan usually checks the file names of listings of an FTP directory or matches regexps on HREF elements of HTML documents. It is not very suitable for CVS revisions and mostly only useful if some original source package is downloadable somewhere.
Do I even need such a file?
No, not at all. :-) But your current does not serve anything, you should remove it then.
Do I need dh_lisp? cl-launch doesn't need a lisp implementation.
You don't need it for cl-launch. I was just making a suggestion in case you really wanted to interface with the common lisp controller through (un)register-common-lisp-source. Sorry if I have not been clear.
Actually, maybe it'd be better if cl-launch was part of the common-lisp-controller package
I leave the response for that to Peter. ;-) René
Hi. The latest version of cl-launch is here: http://fare.tunes.org/files/cl-launch/ What is the next step (if any) to get cl-launch into official debian? The code is rather stable these days, and full-featured enough. It helped me a lot benchmark a few asdf-based applications on multiple CL implementations. Tested with bash, dash, posh, zsh; with clisp, cmucl, sbcl, openmcl and (with partial success) gclcvs. Home page: http://www.cliki.net/cl-launch [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Men, it has been well said, think in herds; it will be seen that they go mad in herds, while they only recover their senses slowly, and one by one. -- Charles Mackay
participants (2)
-
Faré -
René van Bevern