#966640 build-depends: debhelper-compat (= 13) cannot be satisfied

Package:
aptitude
Source:
aptitude
Description:
terminal-based package manager
Submitter:
rharwood
Date:
2024-01-20 12:54:13 UTC
Severity:
important
Tags:
#966640#5
Date:
2020-07-31 20:28:48 UTC
From:
To:
Hi Sam, Ben, Russ,

I think the debhelper-compat version is out of date:

    rharwood@eesha:~$ sudo aptitude build-dep krb5
    [sudo] password for rharwood:
    Unable to satisfy the build-depends: Build-Depends: debhelper-compat (= 13)
    Unable to apply some actions, aborting
    rharwood@eesha:~$

Thanks,
--Robbie
#966640#10
Date:
2020-08-01 02:31:04 UTC
From:
To:
rharwood <rharwood@club.cc.cmu.edu> writes:

13 is the current compatibility level and is provided by the debhelper
package.  I think there's something missing from your environment.  Could
it be Debian stable instead of unstable, for example?  If so, you'll need
to enable backports to get a current debhelper if you want to build the
unstable version of krb5.
#966640#15
Date:
2020-08-01 02:31:04 UTC
From:
To:
rharwood <rharwood@club.cc.cmu.edu> writes:

13 is the current compatibility level and is provided by the debhelper
package.  I think there's something missing from your environment.  Could
it be Debian stable instead of unstable, for example?  If so, you'll need
to enable backports to get a current debhelper if you want to build the
unstable version of krb5.
#966640#20
Date:
2020-08-03 17:02:58 UTC
From:
To:
Source: krb5
Followup-For: Bug #966640

Hi, no, my system information is as reportbug put it in the footer - testing
with unstable and experimental available.

Some more information:

    rharwood@eesha:~$ aptitude versions debhelper
    i A 13.2     testing,unstable     700
    rharwood@eesha:~$ aptitude show debhelper-compat
    No candidate version found for debhelper-compat
    Package: debhelper-compat
    State: not a real package
    Provided by: debhelper (13.2), debhelper (13.2), debhelper (13.2), debhelper (13.2), debhelper (13.2)
    rharwood@eesha:~$ sudo aptitude install debhelper=13
    Unable to find a version "13" for the package "debhelper"
    Unable to apply some actions, aborting
    rharwood@eesha:~$ sudo aptitude install debhelper=13.2
    debhelper is already installed at the requested version (13.2)
    debhelper is already installed at the requested version (13.2)
    No packages will be installed, upgraded, or removed.
    0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
    Need to get 0 B of archives. After unpacking 0 B will be used.

    rharwood@eesha:~$

In debian/control, you list the dependency as:

    Build-Depends: debhelper-compat (= 13)

Could it be because 13 != 13.2 ?

Thanks,
--Robbie
#966640#25
Date:
2020-08-03 18:15:22 UTC
From:
To:
    rharwood>     Build-Depends: debhelper-compat (= 13)

    rharwood> Could it be because 13 != 13.2 ?

No, for a while now virtual packages can be provided at a specific
version.
from apt-cache show debhelper, I see:

Provides: debhelper-compat (= 9), debhelper-compat (= 10),
debhelper-compat (= 11), debhelper-co
mpat (= 12), debhelper-compat (= 13), dh-sequence-dwz,
dh-sequence-elf-tools, dh-sequence-instal
linitramfs, dh-sequence-systemd


I can reproduce your issue with aptitude but not with apt-get.
Which admittedly is surprising because in the past the aptitude resolver
has been better than the apt resolver.
But apparently it does not deal with provides of versioned packages.

The krb5 package is following the recommended syntax in the debhelper
manual.
Given that, I think it's reasonable for aptitude build-dep to be
expected to handle modern debhelper dependencies, so I think you've
found an aptitude bug.
#966640#30
Date:
2020-08-04 00:20:51 UTC
From:
To:
Aha, makes sense.  Sorry to bother!

Thanks,
--Robbie
#966640#37
Date:
2020-08-04 10:02:30 UTC
From:
To:
Hi,

Debian Bug Tracking System wrote:

Yeah, this is a long-standing and known issue in aptitude.

		Regards, Axel
#966640#48
Date:
2020-08-04 11:40:02 UTC
From:
To:
    Axel> Control: forcemerge 509100 -1 Hi,


    Axel> Yeah, this is a long-standing and known issue in aptitude.

I'd ask the aptitude developers to consider whether this issue should be
reprioritized as important rather than normal.
Here's my rationale.
Last year, we decided that the recommended way to build most packages is
to use debhelper.
The recommended way to describe a debhelper compatibility level is a
dependency of the form

debhelper-compat (= 13)

That is, a dependency on a versioned virtual package.

So, aptitude build-dep is not able to process build dependencies on the
recommended way of describing Debian source packages.
As more and more packages adopt this recommended approach aptitude
build-dep is going to become more and more useless.

Even if you are not able to fix the problem promptly, would it be
possible to detect detect that this situation is happening in the
build-dep path and recommend  using a different resolver?
#966640#55
Date:
2020-08-04 13:40:59 UTC
From:
To:
Hii Sam,

Sam Hartman wrote:

Good point, thanks! Done herewith. (And Cc'ed to the master bug report
on this.)

Totally valid point.

Ack.

Another potential not full-blown, but more suitable solution would be
let libapt's resolver translate and maybe even resolve the build-deps
into non-virtual packages and then continue with them as if they would
be the build-depedencies.

Only drawback I see so far: No possibility to interactively choose an
alternative resolution for virtual packages, if there's one.

Manuel: What do you think of this variant?

		Regards, Axel
#966640#60
Date:
2024-01-20 12:50:59 UTC
From:
To:
I found a workaround. If you need to install build dependencies for
package X, just create a fake package, which has "Depends", which are
equal to X's "Build-Depends". Then install this fake package via
aptitude.

Possibility of such workaround means that aptitude already has all
needed machinery. We just need to make aptitude to treat
"Build-Depends" in similar way to "Depends"