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

[David Farning]

On Mon, Sep 21, 2009 at 2:51 AM, Jonas Smedegaard <dr at jones.dk> wrote:
> 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.

I think the biggest piece was that modifying upstream 'forced' down
streams to make a choice between picking into a choice between
adopting the new method(which meant both learning a new sparsely
document method and adopting their current packages to that method) or
forging on ahead with the old method.

You make a decision to break backwards compatibility.  Down streams
_never_ like that.

The last time I did any packaging was during the 'ice weasle/fire fox'
dust up. I started with no preconceived ideas about how packing should
be done.  I pinged Bernie off list how to get started.  He pointed me
to git.debian.org and told me to grep for sugar.  The just try build
the packages on the new disto.  He warned me that the challenges would
be due to build system version mismatches and dependancy issues.  I
manually added the dependancies from alsroots jhconvert packages and
started building.

The documentation worked well enough to create a basic build.  I don't
understand packaging well enough to answer the complexity issues.

>> 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.
>
> Indeed.
>
> 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...

I scheduled .deb packaging as my fun learning project for the .88
release cycle:) I will try to hack away at it  2-3 hours a night for
the next 6 months.  So it might be a while before I have time learn
about, test, and respond to your recommend work flows.

david

> 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.
>
> Regards,
>
>  - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJKtzB4AAoJECx8MUbBoAEhZTsP/0E5tEYvVrHzqQRinpvcDt1a
> iI2eb7H+j0ZfpRBINQEM/ehSvAB3Jk+wMVxydAKuzEglBvFkRLW1N0abgOF6uihE
> 2BK9RMO3SXUyIkUg0WMd+DLwm3d+RBuF8OVoS6t1gCSedczPZ6fYmnZQmfKIS4La
> amsLkbfwz5ZVBa+GxoDynFyhBqaEpMvpNpZ5BpiWR4lsjUfalRSlzviKpnBFaeOO
> uAexbDuPM88SKRrvJ5Bpm1ie9BlLeB553ap3SW+n4CvJ/LghrKRbJ6QzU2DJBc/W
> cRMntPn+r4lzybQ7ENsq5SdJ8Dt1+2ZioR0pPIPwz4+wkdvVvQcSTQe27Vm3D0SQ
> GSOrvAPDF6CkzPZ85l0vgCyb74FC+QWIbILYKF8gGKrAss5djBiGqgTAKAHPcNrF
> FZir6jcC7YjclPxYxbECcXThOlO7Sc/gj8ZRcRaWez9L+JiAQSE3txgEOO3Dvk7J
> 9noRSDiNsA/h4JlAyHNh4dnz1/lgf9ZB6J90xMDwBiiHBCNRJpWXPwp7Z5MsABH0
> 2i8pJXD9ZOaLJgFoa14DyZ2v12QhRMC8SwH+YBgy9JzDO928yqTvc43XNk8M5yAT
> 3+OQFrIuocl3W4PjZQ9kKTKHbD8UJCUpD6qDBvpxhLeUG2eCHfdQsXCJILgsMDqi
> iX3zlmLV05JmeDno6bS5
> =R/y9
> -----END PGP SIGNATURE-----
>
>