On Mon, 2022-11-14 at 13:38:30 +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Guillem Jover (2022-11-14 13:17:34) > > On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote: > > > The way I chopped dpkg-checkbuilddeps was a first approximation. Given > > > that now we have `apt-get satisfy`, my next step would be to have my > > > hacked version print a list of arguments for it, which can include > > > "Conflicts:", but which can already be preprocessed to reduce some noise > > > like packages required or not required from the target architecture. > > > > Ah, so from this I gather that in essence what we need is a way to map > > from build-dependencies into run-time dependencies, removing/filtering > > them from anything that is not accepted in the latter. That makes > > sense and does not seem to have the concerns of the previously filed > > bug request, as that required performing decisions in a layer too low > > where that required information was not available. > > > > I could see gathering any build-dependency fields as restricted by > > (-A/-B/-I), remapping them based on current arch/profile, then > > outputting them as a pair of Depends/Conflicts fields (perhaps even > > an Architecture field if there was arch-restrictions applied?). For > > «apt satisfy» you might need to trim the «Depends: » part though. > > > > Would that work for you? I think it would work for pbuilder. > > > > > More generally, I'd like Debian to have, as a standard, something > > > similar to `rpmspec --parse filename.spec | grep BuildRequires` > > > because I see it reimplemented so many times (pbuilder, sbuild, and so > > > on) that my instincts screams invoking the rule of three and > > > refactor[2]. > > > > I think the above would solve your problem, and potentially could > > substantially reduce the code in pbuilder-satisfydepends. For sbuild > > and mk-build-deps (devscripts), which are already in perl, that would > > only potentially help if this is included as part of a public module. > > So I'll be going that way in case they want to (eventually) switch. > > As far as I can see, this additional feature will not break anything in > sbuild, > so I think I was CC-ed because the question is whether sbuild can use this? In > an earlier mail, Enrico writes:
Sorry, probably the phrasing and placement of my reply made this unclear, with above I meant my previous reply, where I was referring to adding new code in a module to handle this mapping, the bulk of that mapping is already being done by deps_parse(), so I was thinking something a bit more higher-level, but I've not checked the various implementations (including the ones within dpkg-dev), whether they'd benefit from something more higher-level than deps_parse(). I'd imagine something taking a source deb822 control stanza from debian/control or the entire thing, and then mapping build-dependencies in there into Depends and Conflicts (according to some selectable criteria or similar). Thanks, Guillem
