[Sugar-devel] [Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
Jonas Smedegaard
dr at jones.dk
Mon Sep 21 03:51:24 EDT 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.
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...
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090921/81b375a1/attachment.pgp
More information about the Sugar-devel
mailing list