[Debian-olpc-devel] Fwd: sugar

[Jani Monoses]

Hello,


> Yes, I noticed your packages, and had a look at them back in november.
>
> I decided to repackage from scratch with the following goals:
>
>   * Support both Python 2.4 and 2.5
>
>     Debian use Python 2.4 by default, not 2.5 as Ubuntu and upstream.
>     Supporting both means we can test if problems persist in both
>     versions, by switching at runtime.
>

I think most packages use python-central so I think it should work with
both.
Anyway IIRC upstream has some dependencies on 2.5 does it not?


>
>   * Use cdbs
>
I think all my packages were using CDBS from the beginning.


>
>   * Use upstream build routines
>
>     Sugar activities are really just files thrown into a directory.
>     But this might change, and we might miss when that happens. So
>     instead of "reinventing the wheel" I deliberately use upstream
>     Python modules to "throw" the activities into place, instead
>     of just the easier debhelper routines.


makes sense even though it is a lot more work :)

>
>
>   * Dependencies as loose as possible
>

makes sense.


>   * Careful version scheme


sure. Back in november my packages were not in the main archives but in a
PPA
so for expediency and getting more testing I did not pay too much attention
to such details
especially since back then upstream was updating at a rapid pace and version
numbers changed often.


>
>
> >From what I have seen your sugar package includes base, sugar and
> >artwork. These are separate tarballs upstream does that not cause
> >difficulties inthe long term? Sugar especially has recently been split
> >(this year) to sugar and sugar toolkit.
>
> No, those packages are split:
>

Ok I probably missed that.

>
> Source package sugar-core builds binary package python-sugar
>

this is sugar itself not necessarily a module? You could say it's an app
written in python,
I am not sure if the policy requires a python prefix in this case too.

I tried sticking to upstream naming where it made sense.


>
> Source package sugar-toolkit builds binary package python-sugar-toolkit.
>
> Maybe you simply overlooked those names different from the ones in your
> packages?
>

quite possibly. I saw one upload only in debian a few weeks ago and I got
the idea that
it used one source package for 3 upstream core components.


> The names are different in an attempt to comply with Debian Python
> Policy, that says public Python modules should be named as
> "python-<module-name>".


I see.

Actually the packaging details do not matter as much as they can be easily
synced in either direction
between debian and ubuntu. The conflicting package names or even worse (I
suppose this is not the case here)
conflicting package contents are the ones that cause most problems when
working on both distros.
I am sure that debian packages as they are are working well on ubuntu
(provided they are stable on debian)
so the only things I think need changing in the future is the resolution of
the name conflicts for easy upgrades.

thanks
Jani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20080402/851da9df/attachment.htm