[Debian-olpc-devel] Fwd: sugar

[Jonas Smedegaard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 02, 2008 at 10:29:56AM +0300, Jani Monoses wrote:
>Hello all,

Hi Jani,

[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
     anyway... :-P


>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 
packages?

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



Kind regards,

  - Jonas

- -- 
* 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)

iD8DBQFH80bSn7DbMsAkQLgRAsQgAJ4smgypUu2UdF+nxsejlrbKKfq7kACfRM/x
zaFmIQfN2mYPO0qUDGoI7dU=
=mOkg
-----END PGP SIGNATURE-----