[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Bug#956931: autopkgtest: Build profiles support for autopkgtest






-------- Forwarded Message --------
Subject: Bug#956931: autopkgtest: Build profiles support for autopkgtest
Resent-Date: Thu, 16 Apr 2020 20:42:01 +0000
Resent-From: Jiri Palecek <jpalecek@web.de>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: jpalecek@web.de, Debian CI team <team+ci@tracker.debian.org>
Date: Thu, 16 Apr 2020 22:38:07 +0200
From: Jiri Palecek <jpalecek@web.de>
Reply-To: Jiri Palecek <jpalecek@web.de>, 956931@bugs.debian.org
To: Debian Bug Tracking System <submit@bugs.debian.org>


Package: autopkgtest
Version: 5.12.2~6.gbp89ad39
Severity: wishlist

Dear Maintainer,

with the latest and greatest changes in dpkg, I think it would be nice
if autopkgtest followed suit. Particularly, it would be advantageous to
support running and building tests in autopkgtest under build profiles
(esp. nodoc!). This would allow for smaller test footprint, less
packages to pull (ie. you don't need texlive on the testbed), and faster
building of the packages.

I prepared a patch implementing such a change here:
https://salsa.debian.org/jpalecek-guest/autopkgtest/-/commit/6275da59305d6e836cb3558f9f442479eb24fc95

The patch is functional, albeit incomplete due to missing documentation.

The real issue is the control file format. In my patch, I use an extra
stanza to specify build profiles, like this:

Build-Profiles: nodoc

Tests: run-some-tests
<<<

I chose this format, because adding the specification to some of the
tests would be IMHO misleading: the build profile applies to all of the
tests indiscriminately, not to any particular one. Also, I chose to
apply them to all @builddep@ dependencies as well.

However, there is a problem about this: it makes the control file format
non-backwards-compatible. Particularly, dpkg needs to be patched or it
will croak on packages with such d/t/control. Maybe, some artificial
Tests: line like

Tests: *

could be added? That would make the change backwards compatible. Dpkg
still needs to be patched, but the change would be rather minimal.

What do you think about this proposal? Please comment here or on
salsa. I'm also CC-ing the dpkg developers, since it concerns them.

Regards
Jiri Palecek

-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: i386 (i686)
Foreign Architectures: amd64

Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii apt-utils 2.0.1
ii libdpkg-perl 1.20.0+nmu2~1.gbpcd9614
ii procps 2:3.3.16-4
ii python3 3.8.2-2
ii python3-debian 0.1.36

Versions of packages autopkgtest recommends:
pn autodep8 <none>

Versions of packages autopkgtest suggests:
pn lxc <none>
pn lxd <none>
pn ovmf <none>
pn qemu-efi-aarch64 <none>
pn qemu-efi-arm <none>
pn qemu-system <none>
ii qemu-utils 1:4.2-2
ii schroot 1.6.10-9
pn vmdb2 <none>

-- no debconf information

Reply to: