[Debian-olpc-devel] [Sugar-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!

Jonas Smedegaard dr at jones.dk
Mon Sep 21 07:51:24 UTC 2009

On Sun, Sep 20, 2009 at 07:30:07PM -0500, David Farning wrote:
>A couple of months ago your packaging systems was pretty new.... and 
>confusing.  Yesterday I was able to build test packages for GnewSense 
>and Ubuntu.  Pretty Cool.

Yeah, that is certainly great news.  The failure for some enthusiastic 
developers to get a grip about my packaging style back in spring was 
really frustrating, and I have since then refleced a lot on whether my 
approach was bad or just needed improvements and better documentation.

As you can see, I still believe in the approach :-)

When you succeeded now, do you think that is due to you being more 
familiar with the design now that you work more on it, or do you suspect 
that it is my tightening of the structure itself and the rewritten 
README.Source that helped you?  It is interesting for me to know if it 
might make sense to encourage others with "take a break, and look at it 
in 6 months from now, then maybe you'll get a grip" or how else to 
approach the challenge of the dsign being complex.

>This what I was trying to ask, if rather unclearly.  Downstream 
>projects will require minor modification of your /Debian dir to 
>accommodate different policies, build tools, and distro dependency 
>versions, ....
>I am wondering, since we are creating fresh downstream package with a 
>new build-tool, how can we create a useful work flow for both upstream 
>and downstream.  With down streams using git-buildpackage and cdbs, it 
>seems pretty straight forward to ensure that useful patches make it 
>back to git.debian.org.


The least complex is if GNewSense (as an example) is downstream of 
Debian - rather than mix'n'match Debian and Sugarlabs.  Perhaps if I 
draw it...

Here's a mapping between Sugarlabs and Debian development:

Sugarlabs             Debian
=========             ======
VCS     source        VCS              source

         N.tar.bz2 -o- pristine-tar -o- N.orig.tar.gz
                   \                                  \
                    o- upstream ----                   o- N.deb
                   /                \                 /
master -----------                  o- N.diff.gz ----
                       master ------

Here's how I propose to use my packaging structure, for easiest "giving 
back" to Debian:

Debian             GNewSense
======             =========
VCS                VCS              source

pristine-tar ----- pristine-tar -o- N.orig.tar.gz
upstream --------- upstream ----                   o- N.deb
                                 \                 /
                                  o- N.diff.gz ----
master ---------o- master ------

The crucial part is the links between VCS'es: only the master branch 
derives - pristine-tar and upstream branches are mirrored but never ever 
edited directly.  New Sugarlabs upstream releases and Git commits are 
only pulled through Debian - so that we stay in sync.

The reason for mirroring pristine-tar and upstream is for 
git-buildpackage. It might be possible (I haven't tried) to not mirror, 
but instead adjust debian/gbp.conf (in master branch) to point to remote 
branches for pristine-tar and upstream.  That would be better, as then 
GNewSense developers do not accidentally derive further away from Debian 
(git-import-orig should then fail rather than break the chain).

Hope that makes sense, and pleases GNewSense and other potential peers.


  - Jonas

* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20090921/81b375a1/attachment-0001.pgp>

More information about the Debian-olpc-devel mailing list