Minimize installed packages from -proposed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Auto Package Testing |
Fix Released
|
Wishlist
|
Martin Pitt | ||
britney |
Fix Released
|
Wishlist
|
Martin Pitt | ||
autopkgtest (Ubuntu) |
Fix Released
|
Wishlist
|
Martin Pitt |
Bug Description
It sometimes happens that a package P in -proposed gets stuck because one of its dependencies D also gets uploaded and is broken. Right now we always run all tests against the entirety of -proposed, which will cause P's tests to fail due to the broken D.
However, in many cases P's dependencies will be satisfiable in -release, so if we would run tests only against P's -proposed binaries and only use those packages from -proposed which are necessary to satisfy the dependencies (to catch library transitions or packages with versioned Depends: which need to land in lockstep) we could land P and still keep D in -proposed.
This needs fleshing out, and we need to figure out how to do that with apt pinning.
Once we do that, we need to become strict in britney about always respecting the recorded triggering package in the result logs. We must then not consider newer test results which were run against a different trigger Q as an updated test result for a failing test against P. We currently only do this results-per-trigger tracking for kernels, but not for normal packages as the triggering package currently doesn't influence the test results there.
Related branches
Changed in auto-package-testing: | |
status: | New → Confirmed |
importance: | Undecided → Wishlist |
Changed in auto-package-testing: | |
status: | Confirmed → Triaged |
assignee: | nobody → Martin Pitt (pitti) |
Logic for apt pinning:
- take the list of binary packages produced by the triggering package
- give these binary packages a pin priority of 900
- give wily-proposed a pin priority of 100
- give wily a pin priority of 900
Example (taken from a current package in update_excuses, libmatio, that lists a depends on another package in -proposed, hdf5):
Package: libmatio-dev libmatio2 libmatio2-dbg libmatio-doc
Pin: release a=wily-proposed
Pin-Priority: 900
Package: *
Pin: release a=wily
Pin-Priority: 900
Package: *
Pin: release a=wily-proposed
Pin-Priority: 100
I have confirmed that with the above pin, if you do 'apt-get install libhdf5-dev', you get libhdf5-dev from wily; and if you do 'apt-get install libmatio-dev', you get libmatio-dev plus the necessary hdf5 deps from wily-proposed.
Caveat: you will get libhdf5-10 installed, which is only available in -proposed. You will *not* get the -proposed version of libhdf5-dev installed, since the version of libhdf5-dev in wily satisfies the dependency of libmatio-dev. So instead you'll get libhdf5.so (or whatever) pointing at libhdf5.so.8, while libmatio.so.2 is linked against libhdf5.so.10. This should *usually* not be a problem in practice. If it were a problem, I don't see a way to automatically fix it anyway with pinning, because you can't transitively pin things.