On Fri, 10 Jul 2015 05:08 Martin Pitt <[email protected]> wrote:
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? This actually sounds like a good approach. I always thought it was slightly unorthodox for a test payload to be responsible for the installation of the thing it's testing. I'm not aware of anywhere we are depending on that for things to work so maybe we can remove it, at least for those packages that cause a problem? Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
