[Debian-olpc-devel] 'rainbow' uploaded to mentors.debian.net

[Luke Faraone]

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
> better.


lfaraone at stone:~/Projects/ppt/rainbow$ lintian -iv
libnss-rainbow_0.8.4-1_amd64.deb
N: Setting up lab in /tmp/uxZs0eL6Uf ...
N: Processing 1 packages...
N: ----
N: Processing binary package libnss-rainbow (version 0.8.4-1) ...
W: libnss-rainbow: package-name-doesnt-match-sonames libnss-rainbow2
N:
N:    The package name of a library package should usually reflect the
soname
N:    of the included library. The package name can determined from the
N:    library file name with the following code snippet:
N:
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\.//'
N:
N:    Refer to Debian Library Packaging Guide chapter 5 (shared library
N:    packages) for details.
N:
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
>>> Policy.
>>>
>>>
>> 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
> all.
>
> 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
the case.

-- 
Luke Faraone
http://luke.faraone.cc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20091117/e181e3bc/attachment.htm>