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

[Jonas Smedegaard]

On Tue, Nov 17, 2009 at 10:34:59AM -0500, Luke Faraone wrote:
>On Tue, Nov 17, 2009 at 09:16, Jonas Smedegaard <dr at jones.dk> wrote:

>In all honesty, I don't really understand the problem with using the 
>current makefile with Python parts removed.

Ohh - that last part - "with Python parts removed" - makes the whole 
discussion moot: I missed out the fact that you'd patched the makefile 
to avoid invoking distutils.

Yes, that's an elegant approach you did.  Sorry!


That was the Python part. The makefile is still used for compiling the 
NSS library, and you need to ensure that Debian Policy §10.1 is 
respected.  As an example, upstream use -O3 for a security-related 
library, and without being an expert in the area it is my understanding 
that optimizations stronger than -O2 has a higher risk of producing 
wrong code on unusual architectures like hppa.

Using the cdbs makefile.mk snippet is a help, but does not in itself 
ensure following policy - especially with simple makefiles (as opposed 
to autotools-generated ones).



>>> 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.
>>
>
>Well, the package is currently lintian clean. I read through the Debian
>Python Policy, and didn't see anything that conflicted.

Lintian is not an assurance tool, but a helper tool to reveal *some* 
types of packaging flaws.

I am less worried now that you mention actually having verified against 
the Python Policy - and even more so now that I've realized that in fact 
you _do_ rely on the cdbs python-distutils.mk routines rather than let a 
simple makefile possibly mess it up.

Again, sorry for not realizing sooner that you'd patched the makefile.


>The only reason I had to hand-code was because the same structures you 
>referenced didn't build a usable package when I attempted to use them. 
>I more than welcome any changes you would suggest to get these defaults 
>to work without odd hacks.

I believe that now after you've moved the Python code to a 
policy-compliant python-* package you can drop the 
DEB_PYTHON_MODULE_PACKAGES line from the rules file and still produce 
the exact same result.

I recommend dropping DH_VERBOSE (I consider that flag a debugging aid, 
not generally useful).

I recommend moving DEB_PYTHON_SYSTEM up above all cdbs inclusions (not 
strictly needed but is simpler to look at).

I recommend moving DEB_MAKE_INSTALL_TARGET below cdbs inclusions as 
there is no benefit of declaring it early.  Also I recommend to use 
recursive expansion (drop the colon to use "=" instead of ":=" - the 
latter is harmless in this particular instance but also unneeded).

You still haven't fixed DEB_INSTALL_MANPAGES_myapp (there is no package 
"myapp" so the variable is simply ignored). Also I recommend declaring 
it above rules (but below cdbs inclusions) just for the nice structure 
of it.

I suggest avoiding indented comments, as they are printed at build time 
whereas they (usually, and indeed here) are most relevant when _editing_ 
the rules file.


That's about it.  I can't find more to complain about :-P


 - 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/5ecfb9d9/attachment.pgp>