Hi! [ CCing devscripts, pbuilder and sbuild, as this is about some potential functionality refactoring. ]
On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote: > On Sat, Nov 12, 2022 at 09:30:43PM +0100, Guillem Jover wrote: > > There was a bug filed requesting adding custom output format support > > (#214566) but it was closed “recently”. I think there might be some > > value in that, but not for the intended use the submitters seemed > > to want it. > > > > I'd be interested to know how you'd want to use this new output/option > > as from the PoC script you provide it is not obvious to me, as it > > prints both build-depends and build-conflicts in an indistinguishable > > way, and it includes version constraints and alternative dependencies. > > My specific use case at the moment is setting up a container > *description* (not a container) with all the dependencies I need to do > development on a package[1]. > > I could run apt-get build-dep inside the container and get the > development environment installed, but then I lose the ability of being > able to describe it in a terse way, and I can only do something along > the lines of listing all installed packages in the container and their > versions, which is too noisy for an average bug report. Ok, so basing this description on .buildinfo would not seem to be satisfactory then. > 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. I've pondered for a while to add a dpkg-deb822 to parse and manipulate control data, but perhaps something more specific to source packages would be helpful too, where people want to query the list of binary packages to build (dh_listpackages) and similar stuff, but that's for later. :) Thanks, Guillem
