mk-build-deps cannot install particular version of Build-Depends packages

[Исаев Виталий]

Hello! ​

I need to build a project which depends on the particular version of third-party library:

➜  cat debian/control 

Source: libhole-cpp

Priority: optional

Maintainer: Vitaly Isaev <is...@embarce.ro>

Build-Depends: debhelper (>= 9), cmake, 

    flatbuffers (= 1.2.0-1),

    libboost-dev,

    libboost-system-dev,

    catch

Standards-Version: 3.9.5

However, there are several versions of this package in our repo, including the newer ones:

➜ apt-cache policy flatbuffers
flatbuffers:
Installed: (none)
Candidate: 1.4.0-17
Version table:
1.4.0-17 500
500 http://repo12.mailbuild-2.embarce.ro xenial/local amd64 Packages
1.2.0-1 500
500 http://repo12.mailbuild-2.embarce.ro xenial/local amd64 Packages

Under this conditions mk-build-deps refuses to install the desired version of a package:

➜  sudo mk-build-deps --install debian/control

dh_testdir

dh_testroot

dh_prep

dh_testdir

dh_testroot

dh_install

dh_installdocs

dh_installchangelogs

dh_compress

dh_fixperms

dh_installdeb

dh_gencontrol

dh_md5sums

dh_builddeb

dpkg-deb: building package 'libhole-cpp-build-deps' in '../libhole-cpp-build-deps_1.0.1ubuntu1_all.deb'.

The package has been created.

Attention, the package has been created in the current directory,

not in ".." as indicated by the message above!

Selecting previously unselected package libhole-cpp-build-deps.

(Reading database ... 68846 files and directories currently installed.)

Preparing to unpack libhole-cpp-build-deps_1.0.1ubuntu1_all.deb ...

Unpacking libhole-cpp-build-deps (1.0.1ubuntu1) ...

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Correcting dependencies...Starting pkgProblemResolver with broken count: 1

Starting 2 pkgProblemResolver with broken count: 1

Investigating (0) libhole-cpp-build-deps [ amd64 ] < 1.0.1ubuntu1 > ( devel )

Broken libhole-cpp-build-deps:amd64 Depends on flatbuffers [ amd64 ] < none -> 1.4.0-17 > ( devel ) (= 1.2.0-1)

  Considering flatbuffers:amd64 0 as a solution to libhole-cpp-build-deps:amd64 -2

  Removing libhole-cpp-build-deps:amd64 rather than change flatbuffers:amd64

Done

 Done

Starting pkgProblemResolver with broken count: 0

Starting 2 pkgProblemResolver with broken count: 0

Done

The following packages will be REMOVED:

  libhole-cpp-build-deps

0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.

1 not fully installed or removed.

After this operation, 9216 B disk space will be freed.

Do you want to continue? [Y/n] y

(Reading database ... 68850 files and directories currently installed.)

Removing libhole-cpp-build-deps (1.0.1ubuntu1) ...

mk-build-deps: Unable to install libhole-cpp-build-deps at /usr/bin/mk-build-deps line 402.

mk-build-deps: Unable to install all build-dep packages​

Could anyone please clarify what's wrong with my build toolchain? I'm on Ubuntu 16.04, devscripts version is 2.16.2ubuntu3.

Sincerely,

Vitaly Isaev

[Adam D. Barratt]

On 2016-08-25 10:44, Исаев Виталий wrote:
> Build-Depends: debhelper (>= 9), cmake,
> flatbuffers (= 1.2.0-1),

This has nothing to do with mk-build-deps. Given this:

> ➜ apt-cache policy flatbuffers
> flatbuffers:
> Installed: (none)
> Candidate: 1.4.0-17
> Version table:
> 1.4.0-17 500
> 500 http://repo12.mailbuild-2.embarce.ro xenial/local amd64 Packages
> 1.2.0-1 500
> 500 http://repo12.mailbuild-2.embarce.ro xenial/local amd64 Packages

apt will prefer to install the latest available version, as listed in
the candidate field, as demonstrated in:

> Starting 2 pkgProblemResolver with broken count: 1
> Investigating (0) libhole-cpp-build-deps [ amd64 ] < 1.0.1ubuntu1 > (
> devel )
> Broken libhole-cpp-build-deps:amd64 Depends on flatbuffers [ amd64 ] <
> none -> 1.4.0-17 > ( devel ) (= 1.2.0-1)
> Considering flatbuffers:amd64 0 as a solution to
> libhole-cpp-build-deps:amd64 -2
> Removing libhole-cpp-build-deps:amd64 rather than change
> flatbuffers:amd64

Regards,

Adam

[The Wanderer]

In other words: the problem here is the fact that apt's priorities in
this regard are messed up.

If there exists a dependency solution which will achieve the result
requested on the command line (here, installing the lower version of the
depended-on package), that solution should be chosen over any which do
not achieve that result; if that solution involves removing or
downgrading packages, it should be presented for confirmation before
proceeding.

If - as is apparently the case - apt does not presently do that, that
should IMO be considered a bug.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Johannes Schauer]

Hi,

Quoting The Wanderer (2016-08-25 15:29:27)

> In other words: the problem here is the fact that apt's priorities in
> this regard are messed up.
>
> If there exists a dependency solution which will achieve the result
> requested on the command line (here, installing the lower version of the
> depended-on package), that solution should be chosen over any which do
> not achieve that result; if that solution involves removing or
> downgrading packages, it should be presented for confirmation before
> proceeding.
>
> If - as is apparently the case - apt does not presently do that, that
> should IMO be considered a bug.

On that topic, see #786609.

Vitaly might want to try doing:

$ sudo apt-get install apt-cudf apscud
$ mk-build-deps debian/control
$ sudo apt-get install \
--solver aspcud -o APT::Solver::Strict-Pinning=false \
-o APT::Solver::aspcud::Preferences="-new,-removed,-changed" \
./libhole-cpp-build-deps_1.0_all.deb

I can also imagine that aptitude will be able to present a solution in this
situation.

Thanks!

cheers, josch

[Paul Wise]

On Thu, Aug 25, 2016 at 9:29 PM, The Wanderer wrote:

> In other words: the problem here is the fact that apt's priorities in
> this regard are messed up.

The same will happen with custom priorities set.

> If there exists a dependency solution which will achieve the result
> requested on the command line (here, installing the lower version of the
> depended-on package), that solution should be chosen over any which do
> not achieve that result; if that solution involves removing or
> downgrading packages, it should be presented for confirmation before
> proceeding.

I don't think that apt should step outside the configured priorities
without instruction from the user. Since apt doesn't currently
interact with the user (but aptitude does), it can only print an
error. That error could be improved with info about alternative
solutions to try that are outside the configured priorities, using the
-t suite and somepkg/suite syntax.

That said, in this case the solution is within the configured
priorities so apt could do better.

--
bye,
pabs

https://wiki.debian.org/PaulWise

[The Wanderer]

On 2016-08-25 at 23:06, Paul Wise wrote:

> On Thu, Aug 25, 2016 at 9:29 PM, The Wanderer wrote:
>
>> In other words: the problem here is the fact that apt's priorities
>> in this regard are messed up.
>
> The same will happen with custom priorities set.

I am referring not to repository priorities, or similar, but to the
priority which it places on achieving the requested result vs. doing
something else.

[Andrey Rahmatullin]

I still miss why a (= x.y) dep cannot by solved in these circumstances.

--
WBR, wRAR

[The Wanderer]

On 2016-08-25 at 23:06, Paul Wise wrote:

> On Thu, Aug 25, 2016 at 9:29 PM, The Wanderer wrote:

>> If there exists a dependency solution which will achieve the
>> result requested on the command line (here, installing the lower
>> version of the depended-on package), that solution should be chosen
>> over any which do not achieve that result; if that solution
>> involves removing or downgrading packages, it should be presented
>> for confirmation before proceeding.
>
> I don't think that apt should step outside the configured priorities
> without instruction from the user. Since apt doesn't currently
> interact with the user (but aptitude does), it can only print an
> error. That error could be improved with info about alternative
> solutions to try that are outside the configured priorities, using
> the -t suite and somepkg/suite syntax.

To clarify or expand on my previous request somewhat:

What I read you as saying is essentially that in the case of multiple
repositories with differing configured priorities, you think that a
dependency solution which does not adhere to those priorities should not
be considered to exist, for purposes of my statement above.

I might be persuaded to agree with that, but at least at a first
impression, I don't think I do. I think that what the user has requested
on the command line should be considered the top priority, so that it is
always possible (with sufficiently clear and explicit syntax) to
temporarily override the "global" priority settings - rather than having
to manually edit those settings, do this install run, then revert the edit.

The fact that such a departure from the configured "global" priorities
is being made should indeed be made very clear in an install-time
prompt, but I am not immediately convinced that it would be better to
fail with an informative error rather than to present such a prompt.

At the very least, any such error should include a statement of the fact
that a solution which would violate the configured priorities does
exist, and explain which priorities need to be adjusted (and/or at least
which package versions, from which repositories having which current
priorities, would satisfy it) in order for that solution to not be ruled
out in this way.

> That said, in this case the solution is within the configured
> priorities so apt could do better.

Agreed.

[Adam D. Barratt]

On 2016-08-26 13:15, Andrey Rahmatullin wrote:
> On Fri, Aug 26, 2016 at 11:06:25AM +0800, Paul Wise wrote:

[...]

>> I don't think that apt should step outside the configured priorities
>> without instruction from the user. Since apt doesn't currently
>> interact with the user (but aptitude does), it can only print an
>> error. That error could be improved with info about alternative
>> solutions to try that are outside the configured priorities, using the
>> -t suite and somepkg/suite syntax.
>>
>> That said, in this case the solution is within the configured
>> priorities so apt could do better.
> I still miss why a (= x.y) dep cannot by solved in these circumstances.

It would at the very least be a modification to the way apt's solver has
"always" worked, as per apt_preferences(5)[1], so one would need to be
careful when trying to change it.

Regards,

Adam

[1]

"
APT then applies the following rules, listed in order of
precedence, to
determine which version of a package to install.
...
· If two or more versions have the same priority, install the
most
recent one (that is, the one with the higher version number).
"