<div class="gmail_quote">2009/11/16 Jonas Smedegaard <span dir="ltr"><<a href="mailto:dr@jones.dk" target="_blank">dr@jones.dk</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why do you include the version number of the NSS module? I suspect only shared libraries should include a trailing major version, and that NSS modules are not normal shared libraries. Again, compare with other NSS modules for how they do things (without duplicating blindly - e.g. we use CDBS while some of them might use incompatible debhelper 7 "dh").<br>
<br>
</blockquote>
<br>
At least two NSS modules include trailing version numbers. Lintian was tossing a warning unless I did so. If you'd rather, I can drop it and silence Lintian.<br>
</blockquote>
<br></div>
What was the lintian warning? I would like to understand the issue better. </blockquote><div><br><span style="font-family: courier new,monospace;">lfaraone@stone:~/Projects/ppt/rainbow$ lintian -iv libnss-rainbow_0.8.4-1_amd64.deb </span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: Setting up lab in /tmp/uxZs0eL6Uf ...</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">N: Processing 1 packages...</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: ----</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">N: Processing binary package libnss-rainbow (version 0.8.4-1) ...</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">W: libnss-rainbow: package-name-doesnt-match-sonames libnss-rainbow2</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">N: </span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: The package name of a library package should usually reflect the soname</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">N: of the included library. The package name can determined from the</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: library file name with the following code snippet:</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">N: </span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//'</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: </span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">N: Refer to Debian Library Packaging Guide chapter 5 (shared library</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: packages) for details.</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">N: </span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">N: Severity: normal, Certainty: possible</span><br style="font-family: courier new,monospace;"><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, it seems odd to me if Rainbow do not use some private location _below_ /var for its special structures.<br></blockquote><div><br>I changed it to "var/spool/rainbow/2"<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But that upstream mixture of make and python-distutils is problematic: the makefile handles Python code too simplistic for Debian needs (e.g. simply invokes unversioned python rather than taking into account the packaging hints on which version to use)!<br>
<br>
You should recommend upstream to use autotools with Python integration, as done in the core sugar packages.<br></blockquote><div><br>I'll pass that along.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As workaround until possibly improved upstream, I suggest to avoid using the makefile directly and instead replicate the non-python parts of it in debian/rules. In other words, drop the <a href="http://makefile.mk" target="_blank">makefile.mk</a> cdbs snippet, and instead include <a href="http://makefile-vars.mk" target="_blank">makefile-vars.mk</a>, and attach e.g. $(DEB_MAKE_INVOKE) to the relevant core cdbs rules (tell me if you need help figuring those out) directly in debian/rules.<br>
</blockquote><div><br>I've been unable to find any documentation on <a href="http://makefile-vars.mk">makefile-vars.mk</a>. However, for the moment, I think the package builds correctly. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why set DEB_PYTHON_MODULE_PACKAGES - I believe that should be autodetected if using proper package names. Even if not, I still suspect that you should rename the package to include a leading "python-" to not violate Python Policy.<br>
<br>
</blockquote>
<br>
How about this: I'll split it off into three packages: rainbow, python-rainbow, and libnss-rainbow2.<br>
</blockquote>
<br></div>
That's really two (related) issues here:<br>
<br>
* declaring DEB_PYTHON_MODULE_PACKAGES<br>
* naming binary packages according to Python policy<br>
<br>
The cdbs <a href="http://python-distutils.mk" target="_blank">python-distutils.mk</a> snippet by defeault sets DEB_PYTHON_MODULE_PACKAGES to match Python Policy - so if following policy you should not need to mess with overriding DEB_PYTHON_MODULE_PACKAGES at all.<br>
<br>
If, for some odd reason, you need to set DEB_PYTHON_MODULE_PACKAGES, then you must do it _before_ loading the cdbs snippet, sue to internal limitations of the cdbs snippet (I am author of that code and am working on fixing this limitation, but it is is a slooow process as it needs to be done very careful to not break existing users of the tool).<br>
<div></div></blockquote><div><br> I tried building the package without "DEB_PYTHON_MODULE_PACKAGES = python-rainbow" in debian/rules and without "usr/lib/python*" in debian/python-rainbow.install. Either way, I ended up with a 2.5kb python-rainbow package which didn't include the python module.<br>
<br>Proper way of doing things aside, I think the packages currently comply to Debian policy both in naming and behavior. Please let me know if this is not the case. <br>
<br></div></div>-- <br>Luke Faraone<br><a href="http://luke.faraone.cc" target="_blank">http://luke.faraone.cc</a><br>