> I like this, makes it easily parsible by other programs. That was the intention :-)
> I heard other arguments for and against this. Sometimes I like to > have my build lay around so that I have _exact_ copies of what I > just built, and can go in and see if anything went wrong (make sure > all the DEBIAN files were generated correctly, make sure the > binaries are the correct modes) without tearing apart the .deb I > just made. Valid point. Not really mission-critical :-), but still an argument. > Problem is, even then we have to check the control file before we > clean, because like you said, sometimes they are generated, and that > usually means they are reset to some sort of default when > "debian/rules clean" is run. You remind me of something else: the clean target would also remove debian/substvars, which is necessary to generate the src-deps then. So, ok, I redraw that proposal to shift the source package build to the end... > 1) dpkg-ckbuildeps (build, since using "source" seems to be politically > incorrect :) The name doesn't matter (at least for me :-) > 2) debian/rules clean > 3) dpkg-source -b > 4) debian/rules binary (this would call the dpkg-shlibdeps to gen the > builddeps for -dev packages if needed and add the substvars fields > needed) > 5) dpkg-genbuilddeps (this would add the Build-* fields to the .dsc _only_ > if we didn't build with -B/-b) > 6) Optionally run debian/rules clean (this makes no difference, but it > sounds like some people might want it for ease of use) > 6) sign .dsc/.changes This looks as it should work. dpkg-genbuilddeps should be easy to implement. It just reads debian/control and debian/substvars (analogous to dpkg-gencontrol) and inserts the Build-* fields before the Files: field in the .dsc (which isn't signed yet). I'm just thinking if we could integrate that into dpkg-gencontrol... but that's package-specific :-( Roman
