[buildd-tools-devel] Bug#700317: sbuild -s fails if package has Build-Depends-Indep

Johannes Schauer josch at debian.org
Sun Jan 3 09:31:10 UTC 2016


Hi,

Quoting Ian Campbell (2015-12-30 15:16:13)
> On Thu, 2015-12-24 at 01:07 +0100, Johannes Schauer wrote:
> > Sbuild is for building binary packages. If you want to build a source
> > package,
> > then don't use sbuild but either use:
> > 
> > $ dpkg-buildpackage -S
> > 
> > or
> > 
> > $ dpkg-source -b .
> > 
> > A source package is the *input* to sbuild not its output.
> 
> This is a good point, not a way I'd thought about it until now. I guess
> I was simply confused because I typically run sbuild from a source
> package directory and it automagically makes a .dsc for me.

when run from an unpacked source directory, sbuild first produces the source
package using dpkg-source and *then* runs sbuild on that. I think all of the
above is explained at the very top of the sbuild man page:

 | sbuild rebuilds Debian binary packages from the  correspond‐
 | ing  Debian  source, installing any missing source dependen‐
 | cies.  The build takes place  in  a  dedicated  clean  build
 | environment (chroot), rather than on the host system.
 |
 | sbuild can fetch the Debian source over a network, or it can
 | use locally available sources.
 |
 | sbuild is given a packages to process as the argument  PACK‐
 | AGE[.dsc].  This argument is in the form of either a debian‐
 | ized package source directory, a source package  name  along
 | with  a version in the form package_version, or a .dsc file.
 | If no arguments are given, the current working directory  is
 | passed as an argument.
 |
 | For  arguments  given  as source directories, dpkg-source is
 | first run to produce a source .dsc file. Then,  the  package
 | is  built using the .dsc produced. For arguments in the form
 | package_version, apt is used to download the source package.
 | For arguments given as a .dsc file, sbuild builds the source
 | packages directly. For .dsc files in remote  locations,  the
 | source packages are downloaded first, then built.

Personally I find that this is clear. If it wasn't clear for you, I'd like to
hear which part needs clarification or even better a suggestion of how the
documentation can be improved.

> > If you really, really want sbuild to also generate a source package, then
> > you can add the -s or --source option. As the man page points out, this
> > will run dpkg-buildpackage without the -B option (which would do a
> > binary-only build, limited to architecture dependent packages, which is the
> > default mode of operation of sbuild). Thus dpkg-buildpackage will *also*
> > create a source package *in addition* to the binary packages it creates.
> > This is why all the build dependencies are needed.
> [...
> > If you have an idea how the documentation can be improved to prevent this kind
> > of misunderstanding in the future, I'd be happy to hear it!
> 
> I think adding some of the wording you use above to the --source
> documentation would do the trick. In particular "in addition to the
> binary packages" or something along those lines.
> 
> Maybe you would also want to add "this is the default" to the --no
> -source option?
> 
> One thing I'm still not sure of, is if you run in the mode where a
> source package directory is passed as an argument, and sbuild therefore
> runs dpkg-source -b for you, but you also pass -s, am I correct in
> thinking that a second .dsc will then be generated by dpkg-buildpackage
> and included in the .changes file and that this will be a different
> .dsc (timestamps etc) to the one which sbuild made (which is thrown
> away)?

All these questions should be answered by the following update to the sbuild
man page:


    diff --git a/man/sbuild.1.in b/man/sbuild.1.in
    index 26befe3..65f615a 100644
    --- a/man/sbuild.1.in
    +++ b/man/sbuild.1.in
    @@ -320,11 +320,16 @@ snapshot chroots, since by default the snapshot will be deleted.  Possible
     values are \fBalways\fR (default), \fBnever\fR, and \fBsuccessful\fR.
     .TP
     .BR \-s ", " "\-\-source"
    -Also build source package, i.e. use dpkg\-buildpackage without \-B.
    +Build the source package in addition to the other requested build artifacts. By
    +default, the dsc will not be rewritten because the source package is the input
    +to sbuild, not its output. Even when running from an unpacked source tree
    +sbuild will first build the source package using dpkg-source and then pass that
    +on to the sbuild machinery. Use this option only when you know what you are
    +doing. This will rewrite the original dsc passed to sbuild.
     .TP
     .BR "\-\-no-source"
    -Don't build source package, i.e. use dpkg\-buildpackage with \-B.  This option
    -is the opposite of \-\-source.
    +Don't rebuild the source package. This is the default. It is the opposite of
    +\-\-source.
     .TP
     .BR "\-\-force\-orig\-source"
     When used with in conjunction with \-s, this option forces the inclusion of the


Please help to point out where the update is not clear to you.

> Actually, a second thing I'm not sure of, given that -s says it will run
> dpkg-buildpackage without -B, asking therefore for a .dsc as well as arch and
> indep binaries to be built, shouldn't sbuild therefore be installing all the
> build-deps, both -dep and -indep?

Yes it should and in my tests it does. Can you show me a situation in which it
does not? I see your original report was against sbuild 0.63.2-1.1 so maybe
this problem is fixed by now?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160103/a8a6122d/attachment.sig>


More information about the Buildd-tools-devel mailing list