Bug#753657: mk-build-deps: -i broken

[James McCoy]

On Sun, Jul 06, 2014 at 05:39:26PM +0200, Jan Braun wrote:
> I've been poking at apt-cache showsrc and come to the conclusion that it
> just outputs matching entries in the /var/lib/apt/lists/*Sources files.

Indeed.  Filtering the duplicate stanzas out is easy enough, but there
does seem to be a lack of control for which version should be used.  In
response to #633143 we changed mk-build-deps to use the information from
“apt-cache showsrc” corresponding to the highest version number.

That isn't necessarily what one wants, though, since I could easily see
a common case of wanting to build a dependency package for something in
sid when there's a newer version in experimental.

> For example, adding an additional mirror to sources.list and running
> "apt-get update" added a third identical copy of the polipo description.
> And for xmonad, there's one stanza for version 0.11-6 , which nobody
> else seems to bother to mention:

Well, rmadison sheds some light on this:

$ rmadison --suite unstable,testing xmonad
 xmonad | 0.11-6    | sid    | source
 xmonad | 0.11-6+b1 | sid    | sparc
 xmonad | 0.11-7    | jessie | source
 xmonad | 0.11-7+b1 | jessie | amd64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, powerpc, s390x
 xmonad | 0.11-7+b2 | jessie | mipsel
 xmonad | 0.11-8    | sid    | source, amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x

There are still sparc binaries for 0.11-6, so the source is still
around.  It's even worse for iceweasel:

$ rmadison --suite experimental,unstable,testing -a source iceweasel
 iceweasel | 17.0.8esr-2 | sid          | source
 iceweasel | 29.0.1-2    | sid          | source
 iceweasel | 30.0-1      | sid          | source
 iceweasel | 30.0-2      | jessie       | source
 iceweasel | 30.0-2      | sid          | source
 iceweasel | 31.0~b1-1   | experimental | source
 iceweasel | 31.0~b3-1   | experimental | source

> So apt-cache showsrc seems to be a too low-level interface to use without
> postprocessing.

#633143 suggested supporting <package>/<suite> syntax similar to apt.
That along with <package>=<version> should alleviate these issues.
There's not much room for improving the behavior without such
qualifiers, but those will at least provide a better means for
controlling what happens when relying on showsrc.

> > That can easily be handled by checking for undef,
> 
> That seems very brittle to me.

Agreed.

> | $ mk-build-deps -i foo-2.0.0/debian/control
> | $ [hack stuff, time passes]
> | $ mk-build-deps -i foo-1.2.3/debian/control
> | $ [expect the b-d for 1.2.3 to be satisfied]
> 
> But the second m-b-d call will involuntarily also pick up the
> foo-build-deps_2.0.0_all.deb that's still lying around, and dpkg will
> happily unpack 1.2.3 and then immediately replace it by the 2.0.0 that
> comes after it on the command line.

True, and in this scenario I guess one would be less likely to use the
-r option to mk-build-deps.

> I think you do have the version already extracted, can't you predict the
> full filename?

Yes, I have done something along those lines in my local copy.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20140706/d4e19bb2/attachment.sig>