Train should clean source tree before building.

[Robert Bruce Park]

So we're having some growing pains around the gcc5 story, people are wanting to continue dual landing even though they are technically required to have two different debian/control files depending on what their binary package names are (whether or not they were built with gcc5).

Michi has written a debian/rules that is able to generate the correct debian/control depending on what ubuntu release it's being built for, however this fails in practise because the package build process requires debian/control to exist before debian/rules can be built.

I've discussed this with slangasek and sil2100 and it should not be difficult or unreasonable to modify the source package build process to first call debian/rules for the purposes of generating debian/control. The necessary new code would look something like this (in the chroot):

apt-get build-dep $PACKAGE
./debian/rules clean

And then projects will be free to specify an override_dh_auto_clean that can generate the debian/control file or do whatever other magic they need.

[Łukasz Zemczak (sil2100)]

A feasible solution I think, makes sense in overall. Although I must say that I'm generally not fond of the idea that we would generate packaging dynamically - it makes the situation less clean. And remember that not only debian/control might need to be generated, but also the respective .install files and/or .symbol files.

[Robert Bruce Park (robru)]

Yes, michi's packaging now generates many different .install files as seen here:

https://code.launchpad.net/~michihenning/unity-scopes-api/single-tree/+merge/268433

Also in the hangout I was wrong about the chroot not installing build deps, that already happens, so calling clean is all that was necessary.

[Michi Henning (michihenning)]

Thanks heaps for helping us out here guys!

I agree that the dynamic build script hackery adds complexity and makes it harder for people to figure out what's wrong when something won't package correctly. On the other hand, the gcc5 situation is rather unusual. Long term, the cost of having to apply every change to two trees and getting both of them landed is large. (And, sooner or later, someone will make a mistake there too, accidentally causing the trees to diverge.)

But, one other thing that is useful with generated debian files (even without needing to land things twice): the version info for the library is present in a surprisingly large number of places:

- In CMakeLists.txt, so we can set library name and soname

- In another CMakeLists.txt, so we can install headers to the correct path

- In another CMakeLists.txt, for the pkgconfig file

Because we install two libraries, multiply that by two.

The we have all the install files, symbols files, and control (and maybe on or two I forgot). The point is that if the version number has to change, there is a surprisingly large number places where one has to go change things, and it's easy to get that wrong. With the generated debian approach, I have the version number in exactly one place in a file, and everything else pulls it from there and does the right thing automatically.

This isn't worth doing for a small project, or a project that doesn't ship libraries. But for something our size, I think that's a win.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:cupstream2distro at revision 1043, scheduled for release in cupstream2distro, milestone Unknown