Could save a lot of time in package preparation if we skipped build-depends

[Michał Sawicz]

Context:
<slangasek> I thought we had to use the clean target because it might do things like e.g. generation of debian/control
<didrocks> yeah, a word of warning, but some cmake/autotools project expect the clean target to be run to build the source package
<didrocks> famous example being projects only having autogen.sh
<didrocks> also, same issue with python projects, you need to resolve the imports for setup.py
 hence the only rule that worked was "let's get b-d"
<Saviq> I was just asking whether it's a topic in the dpkg community to potentially introduce something like Source-Depends
 would save hours in the train...
<pitti> no, it's not a topic AFAIK
<didrocks> maybe we can start with a X-Source-Depends and brought the issue upstream? (and if not present, the train fallback to Build-Depends)

Let's think of adding support for X-Source-Depends: (empty a valid value, too!) in the train?

[Michał Sawicz (saviq)]

<pitti> normally you just build-dep on dh-autoreconf, have dh --with=autoreconf (or call dh_autoreconf for non-dh packages), and it'll DTRT
<pitti> avoids lots of noise between package builds, as they are really hard to review and utterly uninteresting
<Saviq> sure, agreed, wonder if there's a solution for setup.py
<Saviq> maybe we can drop b-d in the train and fix packaging instead
<pitti> Saviq: would it be totally unreasonable for train packages to require that they get updated to packaging standards which are only 3 years old, not 10? :-)
<Saviq> pitti, nope, +1 from me
<didrocks> pitti: how would you do it for python project?
<pitti> didrocks, Saviq: OOI, why does building a .dsc need to call setup.py?
<didrocks> bumping version for release
<didrocks> (and so creating version.py)
<didrocks> (I guess some of our packages have the same mechanism in CMakeLists.txt)

[Robert Bruce Park (robru)]

This is blocked by https://bugs.launchpad.net/cupstream2distro/+bug/1416106 as it would be highly inappropriate to invest any more time into cowbuilder, which we shouldn't be using.

Once sbuild is in place, we can look into configuring it to not install build deps during a source build.

Another snag is that we currently manually call './debian/rules clean' which some projects are using to munge their debian/control pre-build. slangasek says calling the clean target without build deps installed is a no-no, so we'll have to stop doing that, and instead hard-code some sort of "well known" hook script, like just invoke './ci_train_pre_build_hook.sh' and tell michi to update his package to define that script instead of debian/rules magic.

[Robert Bruce Park (robru)]

Ok, cowbuilder is no longer used, build deps are no longer installed, and we now have ./debian/bileto_pre_release_hook script.