[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Auto Backporting



Frank Küster wrote:
> For some teTeX (or older TeXLive?) packages, I've used a
> "sarge-backport" (or whatever the stable version was) target in
> debian/rules.  It added a changelog entry with backport version number,
> and it switched some patches and build-deps (in particular, poppler
> wasn't available in stable, and we resorted to build with the embedded
> copy of xpdf code). 
On the VoIP team, we used to have, a while back, an automated
backporting mechanism using build-server.net's infrastructure. Kilian
Krause from the team was operating this for us, along with some other
people, I think Bastian Blank among them.

We had (and there are still semi-maintained remaints) scripts under
debian/backports/$DIST that performed the necessary steps to have
something buildable in each distribution. These were mostly shell
scripts calling sed on debian/control and the likes.
We didn't try, however, to provide feature parity with testing/unstable;
the scripts were allowed to disable a feature if e.g. the respective
shared library was not available in stable. The feature was also
(ab)used for Ubuntu-specific changes (where it wasn't possible
otherwise) and/or backports.

Going a bit off-topic here, the service also provided autobuilding for
*each and every* commit done in the team's repository, for *all*
distributions, including unstable. It prepared apt repositories for all
of the packages/combinations and it was actually similar to what
Ubuntu's PPA is providing now.

All in all, it was a wonderful service and actually helped a lot with
debugging because we were able to point users to a simple way to test a
new version (whether it was stable or unstable users) and report back
immediately if it fixed their bugs.

It is obviously hard to scale on a project basis but I'd be extremely
happy if it was revived even with limited functionality and/or a limited
set of packages or teams.

Regards,
Faidon


Reply to: