Re: dpkg test suite fails on Alpine Linux starting with 1.21.10

[Guillem Jover <guillem@debian.org>]

Hi!

BTW, I've now also pushed fixes to git HEAD, for the test failures with
dpkg-checkbuilddeps, and fixed the test suite to not require coreutils,
which will be part of 1.21.13.

On Wed, 2022-12-07 at 19:50:08 +0100, Sören Tempel wrote:
> Guillem Jover <guillem@debian.org> wrote:
> >  * Might need a makedepends on xz-dev (and remove the xz from depends?).
> 
> The xz dependency was added in 2020 with the commit message "dpkg needs
> xz to create packages and busybox xz only support extraction" [1] is
> this still the case? If so: we do need it to be a runtime dependency.

Sorry the "action items" for this were probably more confusing than
helpful. See below.

> >  * Might need a depends on xz, gzip and bzip2 for $pkgname-dev, not
> >    sure whether one can specify fine-grained dependencies only for
> >    that package though? Perhaps within the dev() function?
> 
> It is possible to just define dependencies for the dev() package. Could
> you explain which part of the dev subpackage needs these compression
> tools though? Unfortunately, Alpine does not have an optional dependency
> concept so if a dependency is just needed by a particular script in a
> package then we tend not to add it.

To handle binary .deb packages, the dpkg-deb program (via libdpkg.a) can
either use the compression libraries or the tools, dpkg uses dpkg-deb
as a backend to extract the contents when installing binary packages but
that should in general not be relevant on Alpine. I think using the shared
libraries is in general better, but I'd only strongly recommend that for a
system where dpkg is the native package manager, otherwise do as you deem
best. But given that the packaging is already linking against the other
shared libraries (bzip2-dev and zlib-dev), I'd say it makes sense to place
xz-dev on the same footing, given that it's the default compressor. So
xz-dev and --with-liblzma.

To handle source .dsc packages, the dpkg-source program is used, and
that one requires the command-line compression tools (xz, gzip, bzip2,
lzma).

You might want to have a peek at the debian/control file for what are
the current hard dependencies there. And I'm happy to clarify any that
might not seem obvious.

> >  * The dpkg-dev might need a depends on dpkg.
> 
> Could you elaborate why this is necessary?

When building packages some of the dev tools require (AFAIR) at least
the following run-time tools:

  * dpkg: to get the build architecture by dpkg-architecture and
    anything calling it or using the Dpkg::Arch modules. While the call
    to dpkg might eventually disappear, this would be switched to parse
    a file shipped by the dpkg (run-time) package anyway.
  * dpkg-deb: by dpkg-name and dpkg-scanpackages to extract information
    from .deb archives.
  * dpkg-query: to locate what package contains a specific shared
    library, but then I guess this is a bit pointless if there's not
    going to be anything installed in the dpkg db anyway.

Thanks,
Guillem