Debian Bug report logs - #740133
apt: fails to install versioned dependencies

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Dan Razzell <danr@activestate.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: apt: fails to install versioned dependencies

Date: Tue, 25 Feb 2014 20:41:57 -0800

[Message part 1 (text/plain, inline)]

Package: apt
Version: 0.9.9.1~ubuntu3
Severity: important

Dear Maintainer,

1) One of our products, call it P, is composed of a set of packages which
express some simple dependencies, never more than three deep at present.

2) Such dependencies are strictly versioned.  That is, if package X 
depends on
package Y then the control file for X version v will specify Y version v.

3) Our package repo holds several versions of each package, accumulated
during the evolution of the product.  The package index is generated in
the simplest way possible:

(cd $repo-dir ; dpkg-scanpackages -m . /dev/null > Packages)

4) There is no issue with "apt-get download" accessing any package at any
version, in other words package search and resolution are functioning as
expected.

5) Our build process for P version v installs a manifest of toplevel 
packages
all specifying version v, which should cause dependent packages also of
version v to be installed.  So, for example:

  apt-get -qy install X1=v # Depends on Y1=v, ...
  apt-get -qy install X2=v # Depends on Y2=v, ...
  ...

5a) This works correctly as long as v is the latest version in
our package repo.  Packages X1, X2..., Y1, Y2, ... are all installed
at version v.

5b) When v is not the latest version of these packages, but say w is,
apt-get reports:

  The following packages have unmet dependencies:
   X1 : Depends : Y1 (= v) but w is to be installed
   X2 : Depends : Y2 (= v) but w is to be installed
   ...

5c) We can work around this behavior by explicitly listing Y1, Y2, ...
in the build manifest as in item (5) with version specified.

6) We conclude that there is no issue with installing the packages 
explicitly
at any desired version.  There is no issue with implictly resolving 
versioned
dependencies either and installing those, /provided/ the version happens to
be the latest available in the repo.

7) But we think it's a severe issue that apt-get fails to install the
dependencies otherwise.  We've shown that it /can/ install each dependency
as requested, at the version requested.  We think it should.  The cause
will probably turn up as nothing more than one or two lines of bad logic.

8) This issue occurs on a variety of Ubuntu versions from 12.04 precise
to latest.

Many thanks,

Dan Razzell
DevOps Engineer, Activestate
www.activestate.com

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- System Information:
Debian Release: wheezy/sid
  APT prefers saucy-updates
  APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 
'saucy'), (100, 'saucy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt depends on:
ii  gnupg           1.4.14-1ubuntu2
ii  libapt-pkg4.12  0.9.9.1~ubuntu3
ii  libc6           2.17-93ubuntu4
ii  libgcc1         1:4.8.1-10ubuntu9
ii  libstdc++6      4.8.1-10ubuntu9
ii  ubuntu-keyring  2012.05.19

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc                      <none>
pn  aptitude | synaptic | wajig  <none>
ii  dpkg-dev                     1.16.12ubuntu1
ii  python-apt                   0.8.9.1ubuntu1
ii  xz-utils                     5.1.1alpha+20120614-2ubuntu1

-- no debconf information

[Message part 2 (text/html, inline)]

Message #10 received at 740133@bugs.debian.org (full text, mbox, reply):

From: David Kalnischkies <david@kalnischkies.de>

To: Dan Razzell <danr@activestate.com>, 740133@bugs.debian.org

Subject: Re: Bug#740133: apt: fails to install versioned dependencies

Date: Thu, 27 Feb 2014 14:10:03 +0100

[Message part 1 (text/plain, inline)]

Control: notfound -1 0.9.9.1~ubuntu3
Control: found -1 0.9.9.1
Control: forcemerge 731520 -1

Hi,

On Tue, Feb 25, 2014 at 08:41:57PM -0800, Dan Razzell wrote:
> dependencies either and installing those, /provided/ the version happens to
> be the latest available in the repo.

The 'candidate' version which apt can choose for installation is chosen
by the pin assigned to a version. Have versions an equal pin the higher
version number wins. See man 5 apt_preferences.
So you are arguing against a fundamental design decision here…

In other words: Your problem doesn't exist in the first place or
is 'easily' solved by pinning.

The rational for this (beside that it reduces the problem space A LOT)
is that a release contains only one (good) version for each package as
upgrades make no sense otherwise.
If you want different versions of a software in your archive, you have
them either in different releases or you provide versioned packages.
Either way, there is a sane way to argue about upgrades then as users
can follow a clear path to get (security) upgrades. Or are you really
expecting your users to upgrade with apt-get install Y=x.y.z each time?


Now, that I said that, there are certain cornercases were it indeed
makes sense to have (temporary!) multiple versions in a release to
allow packages to be installed. arch:any -> arch:all and M-A:same
packages come to mind. Implementing this is tricky though as there is
the danger that it prevents certain upgrades forever…
(merging with the last bug I remember requesting this, there are more)


> as requested, at the version requested.  We think it should.  The cause
> will probably turn up as nothing more than one or two lines of bad logic.

This is like saying "cloud is easy, as there are so many in the sky."
Someone who claims to be a DevOps should know by own experience that it
is silly to say such things without having knowledge about the project…
Anyway: We think you should just give us your two lines patch. It will
probably turn up as nothing more than one or two minutes of good work.


> 8) This issue occurs on a variety of Ubuntu versions from 12.04 precise
> to latest.

You have noticed that this isn't Ubuntus bugtracker, right?

It applies to Debian as well in this case, but you give no indication
that you have tried it and you report it against Debian with an
incorrect version causing trouble for the bugtracking system…
(not talking about the severity inflation and not looking for dups…)
Again, from someone with fancy titles, I would expect more.

(sry if all that sounds aggressive, I am just returning the "favor" as
 I read it, even if I realize that it was probably not meant that way)


Best regards

David Kalnischkies, CEO of a computer science student lifeform incorporated

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 740133@bugs.debian.org (full text, mbox, reply):

From: Dan Razzell <danr@activestate.com>

To: 740133@bugs.debian.org

Subject: Re: Bug#740133: apt: fails to install versioned dependencies

Date: Thu, 27 Feb 2014 11:49:04 -0800

Hello David,

I think you have misunderstood the problem description, as you claim it 
is "easily solved by pinning."  Pinning is exactly what we have reported 
is broken.   One package, pinned at a certain version, declares a 
dependency on another package at the same version, with the clear 
intention of pinning it in turn.  That would be our expectation, at any 
rate, but it doesn't work.  I apologize if this wasn't obvious from the 
description, and hope it is clear now.

You have also taken the position that nobody could require versioned 
dependencies, because (if I understand your argument) only the latest 
version could possibly be of interest, as it is the only "good" version, 
the others being made obsolete.  This may be true in a narrow set of 
situations, but it's not true in general.  The versioning of Ruby gem 
dependencies illustrates this abundantly.  In our case, we have several 
interoperating packages which share a common model, for example an 
API.   This is why they must be installed at a common version.  A newer 
version is not "good" if it breaks the model.  It's quite an ordinary 
situation and I'm surprised that you seem unfamiliar with it.

You're right, you do sound aggressive.  It's not necessary to make 
personal attacks when investigating a bug report.  Let's work on solving 
this issue, not deflecting it.

Thanks,
Dan

Send a report that this bug log contains spam.