Hello everybody! :) Quoting Guillem Jover (2022-11-14 13:17:34) > [ CCing devscripts, pbuilder and sbuild, as this is about some > potential functionality refactoring. ]
thank you! > 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. 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: > 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 like to remove code so that I don't have to care about it anymore. But I don't understand which part of sbuild can be replaced by this. Enrico, can you explain? Thanks! cheers, josch
signature.asc
Description: signature
