Hello,

thank you for maintaining dpkg!

I often find myself[1] in need of a tool that, given a source package,
prints a list of its build depends, given an architecture, a build
profile, and so on.

dpkg-checkbuilddeps does internally generate it, and then only print the
list of packages not currently installed.

Would it be possible to add a way to print the unfiltered list?

I've made something that does it by chopping away the filtering bits
from dpkg-checkbuilddeps (see attachment).

Ideally, it can become a --print-depends/--print-conflicts option to
dpkg-checkbuilddeps, instead of a separate tool. Unfortunately my
perl-foo is too rusty to pretend I could propose a competent patch :/


Enrico

[1] and I'm apparently in good company, considering how many times this
    is reimplemented in various places in Debian

Hi!

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.

Anything is possible, I guess my concern is whether this might create
confusion, or whether this is better solved already by some other
tool? Or if there is no workable alternative, finding the right
semantics to add this.

I don't mind implementing it at all, but I'd like to understand what
this is needed for. :)

Thanks,
Guillem

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.

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.

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].


Enrico

[1] some background context can be found in
https://github.com/ARPA-SIMC/moncic-ci/issues/74
    although I'm expanding on that, see for example
https://github.com/ARPA-SIMC/moncic-ci/issues/77
[2] https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)

Hi!

[ CCing devscripts, pbuilder and sbuild, as this is about some
  potential functionality refactoring. ]

Ok, so basing this description on .buildinfo would not seem to be
satisfactory then.

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.

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

Hello everybody! :)

Quoting Guillem Jover (2022-11-14 13:17:34)

thank you!

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:

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

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