Re: Thoughts about src-dep implementation
> 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
Reply to: