Your message dated Fri, 14 Oct 2022 02:56:11 +0200 with message-id <y0izq8m69fpxy...@thunder.hadrons.org> and subject line Re: Bug#1008206: libdpkg-perl: debs_parse option to reduce invalid package names and version strings has caused the Debian Bug report #1008206, regarding libdpkg-perl: debs_parse option to reduce invalid package names and version strings to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1008206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008206 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: libdpkg-perl Version: 1.21.2 Severity: wishlist Control: affects -1 autopkgtest Dear maintainer, Recently I updated autopkgtest to handle tests that need their Recommends installed in a different way than before [1]. autopkgtest now does that reading the debian/control file of the source and processing the line with Dpkg::Deps deps_parse. Of course I overlooked things. Currently the biggest issue is that variables are allowed in debian/control, as they are substituted during the build process. I have thought about alternatives, but currently I'm reluctant to build another implemtation, as either they are difficult or have other issues. It would be great if debs_parse had an option to reduce package names that are invalid (most importantly `${something}`) or versions that are invalid (most importantantly `(>= ${something})`). What do you think? Paul [1] ``@recommends@`` stands for all the packages listed in the ``Recommends:`` fields of all the binary packages mentioned in the ``debian/control`` file.
--- End Message ---
--- Begin Message ---Hi! On Thu, 2022-03-24 at 12:41:04 +0100, Paul Gevers wrote: > On 24-03-2022 12:28, Guillem Jover wrote: > > 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. > > It's totally OK to say no, even if you're not able to tell me how to fix my > own problem. Sure, I just still like to explore what are the available avenues, before outright closing this kind of request. And in many cases this helps me see current and potential drawbacks in my thinking or potential alternatives or (non-)solutions, etc. > It's more that if you were (very) willing to add that option it > would give me some easy breathing room with that particular issue. Not a > perfect solution, but better than what I have now and probably good enough > in practice. But again, feel free to close this issue as wontfix and I'll > think about my options. Right. I think, I'll just be closing this now. Thanks for understanding! > Either way, thanks for the discussion. Anytime! Thanks, Guillem
--- End Message ---
