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é