Hi, On 18-09-18 17:21, gregor herrmann wrote: > On Mon, 17 Sep 2018 15:11:30 -0700, Antonio Terceiro wrote: > >>> So if needs-recommends vanishes, there will be at least dozens if not >>> hundreds of perl packages which will immediately fail their >>> autopkgtests. >> >> Yes. We will need to find a replacement before dropping needs-recommends >> completely.> > Thanks.
I think autodep8 (which is doing the work for these perl packages) must be fixed before we can remove needs-recommends. It should already add the recommends to the test dependencies. (but see my comments below). >> Maybe we want autopkgtest to also support @recommends@ alongside >> @builddeps@? > > From a user's point of view, that sounds ok to me. > Updating a few bits of documentation and a handful of packages with > manual d/t/control shouldn't be a problem. On the one hand, I wonder what that is going to help. This is just changing semantics as it still means that autopkgtest needs to figure it out. The current situation is going to waste peoples time debugging why a test is a regression, just to find out that every tool is silent on not installing the recommends. On the other hand, it is a clearer statement and it means that we can explain and document what we really mean with it. @recommends@ or needs-recommends should mean that direct recommends of the binary packages from the package that provides the autopkgtest are test dependencies. Implementation wise, this would mean that we would add all recommends, whether the binary that recommends it is installed or not. If the feature to have recommends in the test dependencies isn't going away, how bad would it be if we change the behavior in a sustainable way? In my endeavors to fix this bug, I have missed the option to just add the sum of all the Recommends lines to the test dependencies, like we do with @builddeps@. What do people think? Paul
signature.asc
Description: OpenPGP digital signature
