[Debian-olpc-devel] 'rainbow' uploaded to mentors.debian.net
luke.faraone at gmail.com
Tue Nov 17 13:35:33 UTC 2009
2009/11/16 Jonas Smedegaard <dr at jones.dk>
> 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").
>> 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.
> What was the lintian warning? I would like to understand the issue
lfaraone at stone:~/Projects/ppt/rainbow$ lintian -iv
N: Setting up lab in /tmp/uxZs0eL6Uf ...
N: Processing 1 packages...
N: Processing binary package libnss-rainbow (version 0.8.4-1) ...
W: libnss-rainbow: package-name-doesnt-match-sonames libnss-rainbow2
N: The package name of a library package should usually reflect the
N: of the included library. The package name can determined from the
N: library file name with the following code snippet:
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-/;
N: Refer to Debian Library Packaging Guide chapter 5 (shared library
N: packages) for details.
N: Severity: normal, Certainty: possible
Also, it seems odd to me if Rainbow do not use some private location _below_
> /var for its special structures.
I changed it to "var/spool/rainbow/2"
> 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)!
> You should recommend upstream to use autotools with Python integration, as
> done in the core sugar packages.
I'll pass that along.
> 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 makefile.mk cdbs snippet, and
> instead include makefile-vars.mk, 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.
I've been unable to find any documentation on makefile-vars.mk. However, for
the moment, I think the package builds correctly.
> 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
>> How about this: I'll split it off into three packages: rainbow,
>> python-rainbow, and libnss-rainbow2.
> That's really two (related) issues here:
> * declaring DEB_PYTHON_MODULE_PACKAGES
> * naming binary packages according to Python policy
> The cdbs python-distutils.mk 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
> 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).
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Debian-olpc-devel