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

[Luke Faraone]

On Tue, Nov 17, 2009 at 09:16, Jonas Smedegaard <dr at jones.dk> wrote:
>
>  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.
>>>
>>  Read /usr/share/cdbs/1/class/makefile-vars.mk directly to see what it
> provides.
>

I'm sorry, I read through it, but I'm not really sure how to apply this.

Are you suggesting that I duplicate the upstream makefiles in my
debian/rules file? That seems like it might cause more problems than it's
worth when upstream makes changes to their makefile, and might introduce
subtle bugs.

If the current upstream-provided-makefile is insufficent, would it be more
worthwhile to write a patch enabling Rainbow to use autotools?

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

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.


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

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.

-- 
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/25325404/attachment-0001.htm>