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

[Jonas Smedegaard]

On Tue, Nov 17, 2009 at 08:35:33AM -0500, Luke Faraone wrote:
>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.

I understand now.  Seems to make sense - I just fear that NSS modules 
might have some unique peculiarities...


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

It should not only "build correctly" but also respect optimization flags 
passed at custom builds, and other tricks.

I strongly recommend to rely on well tested structures!

Read /usr/share/cdbs/1/class/makefile-vars.mk directly to see what it 
provides.


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

I fear that Debian _Python_ Policy is not followed accurately.

No, I will not do the quite tiresome job of double-checking if your 
hand-coding is of as good quality as if you relied on well-tested 
structures.


  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20091117/27ed62d7/attachment.pgp>