[Debian-olpc-devel] On activity versioning and testing with multiple Sugar branches
luke at faraone.cc
Wed Jul 14 15:58:18 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
I have been looking at a number of different repositories of the NEW
activities being packaged, and, since they're all sourced from the same
rules file, they all declare "DEB_SUGAR_BRANCHES = 0.86 0.88".
This is fine, if we've actually verified that the activities only work
with those branches. If that's the case, we should rename the activities
Basically, the purpose of DEB_SUGAR_BRANCHES as I understand it is to
tell CDBS which versions of Sugar the activity supports. In Debian, the
team currently maintains 0.84, 0.86, and 0.88. So far, our new team
members have been testing exclusively with 0.88.
So we can ensure the packages are of the widest use possible, we should
test our new activity packages with each of the activity versions. To
1) Temporarily change debian/rules as follows:
* Comment out the "DEB_SUGAR_BRANCHES", "CDBS_PROVIDES",
"CDBS_CONFLICTS", and "CDBS_REPLACES" stanzas.
* Add the following to the rules file:
# We support all branches, but default to 0.88.
CDBS_DEPENDS = python-sugar-0.88 | python-sugar,
python-sugar-toolkit-0.88 | python-sugar-toolkit
CDBS_DEPENDS += , python-hippocanvas, python-telepathy, python-gtk2,
# Override sugar listing
CDBS_BUILD_DEPENDS_class_python-sugar_sugar = python-sugar-0.88 |
python-sugar, python-sugar-toolkit-0.88 | python-sugar-toolkit, unzip
2) Regenerate debian/control from debian/control.in.
3) Build your package.
4) Install "sugar-emulator-0.88" on a Debian system running Squeeze
(testing) or Sid (unstable). This can be a virtual machine, a dual
booted system, or whatever.
5) Install your package on a the same system using gdebi or something
6) Start sugar-emulator and make sure that your package starts.
7) Repeat step 4 replacing 0.88 with 0.86 and test your package.
8) Repeat step 4 replacing 0.88 with 0.84 and test your package.
Note any times your activity fails to function. If it starts in all
versions of Sugar, you're fine, and you can commit your changes to
debian/rules, and commit separately your regeneration of debian/control,
leaving your package as-is.
If it works in 0.86 and above, for example, restore your debian/rules
file to it's original state. Change "DEB_PYTHON_SUGAR_PACKAGES" adding
"-0.86" to the end. Change the binary package name in debian/control.in
adding "-0.86" to the end.
If it works in 0.88 only, do as with 0.86 replacing 0.86 with 0.88.
As always, reply to this mail with any questions, or ask on IRC. If
there are any technical problems with steps I've given, also let me know.
Till next time,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Debian-olpc-devel