[Debian-olpc-devel] Fwd: sugar
dr at jones.dk
Wed Apr 2 08:41:59 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, Apr 02, 2008 at 10:29:56AM +0300, Jani Monoses wrote:
[I have cc'ed you personally, in case you are not subscribed here]
>I have just learned on the sugar list that you rsugar package has been
>uploaded to debian. Congrats :)
Thanks. And congratulations with your earlier work for Ubuntu!
>I have been packaging sugar and related tools in Ubuntu for about a
>year and the core is already in Ubuntu.
>I was wondering if you could consider basing your work on these and
>reduce the effort of making it all from zero.
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.
* Use cdbs
Packaging to "just work" is relatively simple, but ensuring that
Debian Policy and emerging "good practices" is followed gets
complex. Cdbs helps by separating stanadard routines from stuff
unique to a specific package.
I have developed some cdbs "snippets" for Sugar packages, to
simplify even further, while still upholding tight
build-dependencies and other tricky to remember details.
I also encourage using some additional non-required snippets
I have invented, like copyright-check.mk which helps ensure that
debian/copyright is always up-to-date, by failing the build if
copyrights or licenses change in upstream source.
* Use Git
The packaging is maintained in Git, to ease multiple branches -
like packages for Debian and Ubuntu, which might differ in some
parts but other parts we might like to keep in sync.
Using Git rather than other distributed VCS has the added benefit
of easy tracking upstream development.
* 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.
* Dependencies as loose as possible
Instead of just have packages depend strictly on each other, I
spend some time looking through the Python code to decide if
some dependencies are only needed in some corner cases, and
should rather be recommends or suggests instead, in the Debian
packaging logic. This might make no difference for most users,
but as the definition says, recommends is what makes sense only
to most users: I want to pay respect to odd minorities whenever
possible. Like tiny embedded machines with small space, or
strange setups like diskless clients using a custom X11 server.
* Careful version scheme
I try to not release a package with an upstream version number
that was not released officially (like as a tarball) by upstream.
Instead, I use the relatively new invention of "~" to indicate
"just below" - to make room for a possible later rerelease using
official upstream tarball.
I do notie that the version number of some of your packages are
newer than ours. I don't care much about that: you are not
supposed to mix APT sources targeted at different distributions
>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:
Source package sugar-core builds binary package python-sugar
Source package sugar-toolkit builds binary package python-sugar-toolkit.
Maybe you simply overlooked those names different from the ones in your
The names are different in an attempt to comply with Debian Python
Policy, that says public Python modules should be named as
I write "attempt" because really that policy is unrealistic to fulfill:
sugar-toolkit provides more modules than only "sugar.toolkit"...
>You may check out my work in ubuntu 8.04 (hardy). I hope we can
>cooperate especially since there are a lot of activities to be packaged
>in the future and core bits that are not package yet (csound, tamtam,
>etoys, modified evince)
I'd be very happy to work with you on future packaging. But as
described above, I found your starting point unsatisfactory for us.
Could you perhaps be tempted to base some or all of your future work on
our packaging instead?
Or do you have alternative ideas as to how we can move on from here,
that pleases you more?
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Debian-olpc-devel