[Debian-olpc-devel] 'rainbow' uploaded to mentors.debian.net
dr at jones.dk
Tue Nov 17 18:58:34 UTC 2009
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
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 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