Re: Thoughts about src-dep implementation

[Ben Collins <bcollins@debian.org>]

On Wed, Oct 27, 1999 at 02:46:45PM +0200, Roman Hodek wrote:
> 
>    (I = install, U = upgrade, D = downgrade, R = remove, C = comment)

I like this, makes it easily parsible by other programs.

>    The problem with this: Currently the .dsc is built before
>    compiling, and thus the Build-* fields have to be known before
>    dpkg-shlibdeps is run. But there's an easy solution (IMHO): Why
>    don't we build the source package after the binaries? This would
>    speed up the development cycle anyway, because as long as you're
>    experimenting you currently often build the src package
>    unnecessarily. Also, you automatically have cleaned source trees
>    after dpkg-buildpackage, which can save some disk space if you
>    maintain lots of packages :-) At least I can't see now big problems
>    if dpkg-buildpackage runs "debian/rules clean; dpkg-source -b"
>    after building the binaries. Comments?

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.

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.

I suggest this for a dpkg-buildpackage run order

1) dpkg-ckbuildeps (build, since using "source" seems to be politically
   incorrect :)
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

Hopefully this will satisfy all the requirements, I don't think there are
any holes in the process.

Ben