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