Comment 1 for bug 1503150

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.