On Fri, Apr 17, 2020 at 09:56:29AM +0200, Julian Andres Klode wrote: > On Thu, Apr 16, 2020 at 11:04:02PM +0200, Jiri Palecek wrote: > > > > > > > > -------- 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. > > I understand the motivation for testing in-archive, but this creates > a problem for local testing of unbuilt packages. We want to test as > close to the archive as possible, meaning that the packages we test > should be built with the same build profile as in the archive. > > I'm not sure how this is currently handled, but I'd really not > want to go through the trouble of building twice, once without > profiles to get the .debs, and then with build profiles for tests > with build-needed. > > And of course, I don't want to just build with those build profiles, > because then it's different from the archive, and I don't get the > guarantees I want (namely, I want to be reasonably certain that > if I run autopkgtest on my .dsc, that it will built and test > successfully in the archive as well; including docs, obviously). > > So, in summary, I think it's not a good idea. Agreed. FWIW, I would like autopkgtest to be less involved, not more, with building packages at all. I think build-needed tests are a terrible idea, and I would not like to add any involved mechanism to control how autopkgtest builds packages - I think it being able to build packages in the simplest way possible is already too much. If one wants to optimize testing time, they should fix their package so that it can be tested without requiring another build.
Attachment:
signature.asc
Description: PGP signature