[Debian-olpc-devel] 'rainbow' uploaded to mentors.debian.net
dr at jones.dk
Tue Nov 17 14:16:02 UTC 2009
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
>>>> 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
* 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
Size: 836 bytes
Desc: Digital signature
More information about the Debian-olpc-devel