Holding a package that is not installed

[Martin Pitt]

Hey Omer,

Omer Akram [2015-07-10  0:57 +0500]:
> For example: I have unity8 installed and I hold it with 'apt-mark hold
> unity8' since unity8 comes preinstalled on phones, when I try to install
> unity8-autopilot it tries to install the latest version(if available) from
> the archive and fails because it depends on unity8 itself.
> 
> What I am looking for is a way to hold any new package from the same source
> to not try to upgrade to the latest version, rather install the version of
> its sibling package. Probably I could do with pinning ?

This is not generally possible. When unity8 gets updated in the
archive, the older version disappears from the package indexes, so apt
*can't* install an older version. You can still manually fish out the
debs from Launchpad and install them with dpkg, though.

This question comes up time and again for phone testing: You are
trying to use apt on a system which is fundamentally not working with
apt. So in autopkgtest we work around that by downloading the debs
only, unpacking them in /tmp and setting $*_PATH, to make a small
subset of deb test dependencies work. This can only work so far, of
course.

But if you are testing an older phone image and the archive moved
ahead, you often get uninstallables because of library transitions,
new Conflicts:, code incompatibilities, etc. The only workable answer
to this problem would be to have some kind of a per-image "archive
snapshot" with at least all your test dependencies at the time the
touch image is built, and then install test dependencies from that.
This could be a per-touch-image-version PPA, or just a big tarball
with all test dependencies that we need, or at least recording the
current Packages.gz indexes so that we can map them to Launchpad and
get the debs from there. But without any of these, the only thing that
works with the current archive is testing an equally current phone
image.

The other approach is to restrict ourselves to only a small subset of
test dependencies which is less likely to break. autopilot etc.
should be fairly okay as it's reasonably independent from the packages
installed on the touch image, same for stuff like imagemagick. But
unity8-autopilot definitively isn't in that category -- I'd actually
suggest pre-installing this on the touch images until we have this
kind of test dependency archive snapshot from above. This might mean
to relax its dependencies so that unity8-autopilot stops pulling in
the entire autopilot, but that should be okay?

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)