Re: Exclicitly or "implicitly" mark architectures a packages does not build
On Wed, 20 Dec 2017 at 12:51:36 +0000, Ian Jackson wrote:
> Simon McVittie writes ("Re: Exclicitly or "implicitly" mark architectures a packages does not build"):
> > - valgrind (dbus)
> Is this something to do with a test-suite ? Maybe those tests should
> be autopkgtests instead.
No, it would be Build-Depends: valgrind-dev if that package
existed. (Arguably it should: it would be a tiny binary package containing
only a few headers, but it could be Architecture: all, and then packages
like dbus could Build-Depend on it unconditionally.)
> I see in dbus_1.12.2-1.dsc
>
> Build-Depends: ...
> valgrind [amd64 arm64 armhf i386 mips64 mips64el mips mipsel powerpc
> ppc64 ppc64el s390x]
> <!pkg.dbus.minimal>, ...
>
> which is rather WTF. Is this trying to do Build-Recommends ?
Sort of. It's enabling a non-essential feature on (hopefully) exactly
those architectures where it can work, to make programs that use libdbus
slightly more debuggable on those architectures.
Users of other architectures would be upset if dbus and all its
reverse-dependencies weren't buildable on that architecture (there are a
lot of rdeps), but at the same time it seems foolish to reject a helpful
debuggability feature available on most architectures just because there
exist architectures that can't do it.
libdbus contains a memory-pool allocator to recycle small,
repeatedly-allocated structs (quite possibly premature optimization, it
was added long before my involvement), which makes valgrind think memory
is still reachable even when, conceptually, it has been freed. To help
developers debug programs that are linked to libdbus, there's a debug
build that can be pulled in via LD_LIBRARY_PATH or LD_PRELOAD, which
among other things includes special instrumentation (using <valgrind.h>)
to tell valgrind to treat memory that is returned to the pool as though
it had been freed.
smcv
Reply to: