Hello,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>Yes, I noticed your packages, and had a look at them back in november.<br>
<br>
I decided to repackage from scratch with the following goals:<br>
<br>
* Support both Python 2.4 and 2.5<br>
<br>
Debian use Python 2.4 by default, not 2.5 as Ubuntu and upstream.<br>
Supporting both means we can test if problems persist in both<br>
versions, by switching at runtime.<br>
</blockquote><div><br>I think most packages use python-central so I think it should work with both.<br>Anyway IIRC upstream has some dependencies on 2.5 does it not?<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
* Use cdbs<br>
</blockquote><div>I think all my packages were using CDBS from the beginning. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
* Use upstream build routines<br>
<br>
Sugar activities are really just files thrown into a directory.<br>
But this might change, and we might miss when that happens. So<br>
instead of "reinventing the wheel" I deliberately use upstream<br>
Python modules to "throw" the activities into place, instead<br>
of just the easier debhelper routines.</blockquote><div> </div><div>makes sense even though it is a lot more work :)<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
* Dependencies as loose as possible<br>
</blockquote><div><br>makes sense.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * Careful version scheme</blockquote><div>
</div><div>sure. Back in november my packages were not in the main archives but in a PPA<br>so for expediency and getting more testing I did not pay too much attention to such details<br>especially since back then upstream was updating at a rapid pace and version numbers changed often.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
>From what I have seen your sugar package includes base, sugar and<br>
>artwork. These are separate tarballs upstream does that not cause<br>
>difficulties inthe long term? Sugar especially has recently been split<br>
>(this year) to sugar and sugar toolkit.<br>
<br>
</div>No, those packages are split:<br>
</blockquote><div><br>Ok I probably missed that. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Source package sugar-core builds binary package python-sugar<br>
</blockquote><div><br>this is sugar itself not necessarily a module? You could say it's an app written in python,<br>I am not sure if the policy requires a python prefix in this case too.<br><br>I tried sticking to upstream naming where it made sense.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Source package sugar-toolkit builds binary package python-sugar-toolkit.<br>
<br>
Maybe you simply overlooked those names different from the ones in your<br>
packages?<br>
</blockquote><div><br>quite possibly. I saw one upload only in debian a few weeks ago and I got the idea that<br>it used one source package for 3 upstream core components.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The names are different in an attempt to comply with Debian Python<br>
Policy, that says public Python modules should be named as<br>
"python-<module-name>".</blockquote><div><br>I see. <br></div></div><br>Actually the packaging details do not matter as much as they can be easily synced in either direction<br>between debian and ubuntu. The conflicting package names or even worse (I suppose this is not the case here)<br>
conflicting package contents are the ones that cause most problems when working on both distros.<br>I am sure that debian packages as they are are working well on ubuntu (provided they are stable on debian)<br>so the only things I think need changing in the future is the resolution of the name conflicts for easy upgrades.<br>
<br>thanks<br>Jani<br>