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 <guil...@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
