On Thu, 2022-03-24 at 12:08:30 +0100, Paul Gevers wrote: > On 24-03-2022 12:06, Paul Gevers wrote: > > Hi Guillem, > > > > On 24-03-2022 11:50, Guillem Jover wrote: > > > Hmm, but that means autopkgtest will then miss packages that are > > > listed in Recommends fields on the built packages it is supposed to be > > > testing, no? > > > > Indeed. But at least that's what is documented :(.
Given that this was added (AFAIR) quite recently, wouldn't it be an option to try to fix its semantics now instead of carrying this over? (I don't expect things might break, given that I'd expect users would want to test the full recommends and not a partial view?) > > > I think the correct answer here is to take those fields from the built > > > packages, which are to be tested, then you'd get accurate > > > dependencies, and no need to have to deal with substvars. Is that > > > alternative you had in mind and already discarded? > > > > Indeed, but there's no nice interface. E.g. I looked at the output of > > apt-cache depends (with --no-pre-depends --no-depends --no-suggests > > --no-conflicts --no-breaks --no-replaces --no-enhances) but then we miss > > versions and worse, we need to carefully figure out which packages we're > > interested in and which version of those packages we should ask > > apt-cache. This makes it a rather ugly piece of code in autopkgtest. > > And if autopkgtest is asked to build the binaries, apt doesn't yet even > knows about them the moment we want to know these Recommends. So we'd need a > different interface for that code path. Hmm. I'm not sure what other constraints you are working with here. Would fetching the Recommends fields after the fact from either dpkg-query (once installed) or from dpkg-deb -f (on the downloaded or built .debs) be unsatisfactory? In any case, if it seems like I'm trying to evade the initial request, I guess in part it is, because I am. :D I'm afraid adding a mode to handle improper/malformed input would be difficult, because that depends on the amount of “improperness”, and because it looks like a smell that ideally should be fixed elsewhere. For example if you only had substvars that add entire new dependency information, then just using the Dpkg::Substvars replacements with possibly empty variables, could do it, but if as you mentioned these are embedded inside dependency syntax, then that'd be indeed a problem. Thanks, Guillem
