Bug#800240: autopkgtest: allow to use binaries from .changes and source from .dsc without rebuilding
Quoting Martin Pitt (2015-09-27 20:54:27)
> Johannes Schauer [2015-09-27 17:59 +0200]:
> > for using adt-run as a post-build-commands hook in sbuild it would be
> > useful if it would be possible to combine the .dsc that was passed to
> > sbuild with the .changes that was just created by sbuild and which
> > contains the list of built binary packages.
> > Currently it seems that when using:
> > $ adt-run --no-built-binaries --source pkg_1.0-1.dsc --changes pkg_1.0-1_amd64.changes
> > The binaries from the archive will be used instead of the ones in the
> > ..changes file.
> Yes, see man adt-run: All binaries that you want to use for a
> particular test (the .dsc in this case) must come *before* that test.
I don't think the man page is saying anything about the order of the --source
option relative to the --changes option.
I see two mentions of the order being relevant. Once for the --source option:
| The ordering is significant: each --source option should precede options
| whose dependencies are to be satisfied by the binaries it produces.
And once for the --binary option
| The ordering is significant, as for --source. In particular, if a subsequent
| source package will build a binary of the same name, that will be used from
| then on, and deb will be ignored.
And I read both before filing this bug but was unable to see how any of these
applies to the order of options when combining --source with --changes.
So at least this bug should be kept open until the following very valuable hint
> I. e. use "adt-run pkg_*.changes -B pkg_*.dsc" for your use case.
In fact, from the existing docs I interpreted that the --source option must
come after the --changes option as it says that if there source packages
building binary packages of the same name, then they will *overwrite* these
binary packages which is not what I wanted so I thought that the --changes
option should come *after* the --source option.
So I think this should be clarified in the man page.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes