== The use case == I'm building a unity8 snap that includes a lot of the Ubuntu Touch project built into it (unity8, indicators, a whole upstart & dbus session, etc). So when building a snap (locally and in LP), we use the standard Touch overlay archive on top of xenial. For reference, the Touch overlay archive is ppa:ci-train-ppa-service/stable-phone-overlay. But unfortunately due to a lack of manpower, the overlay archive can drift out of sync with xenial-updates for a while and versions in the overlay get hidden by higher versions in -updates. Until someone merges the new release into the overlay again. Traditionally, our solution for that is to build Ubuntu Touch images with the overlay archive pinned above the base archives. I believe this is done directly in livecd-rootfs today. So when building a snap, we can tell all our developers to pin the archive. But that's a bit of a pain (and easy to forget, which leads to subtle bugs later). And LP does not let us pin an archive, so any snaps LP builds will have those same subtle bugs [1]. I asked for LP to offer pinning as part of a snap recipe (bug 1646139), but Colin suggested that I first try to see if snapcraft itself is interested in offering pinning support. Note that this issue affects any snap that bases itself off the Touch overlay. So not only unity8, but probably also all our core unity8 apps. And third-parties might have similar issues. [1] As an example of such a bug, ALSA doesn't work in the LP-built snaps because of a mismatched gstreamers plugin package when pinning isn't done. == The ask == One thing I imagine that snapcraft could do is allow a plugin to specify apt preferences.d modifications, much like it allows a plugin to specify PLUGIN_STAGE_SOURCES. And then use those preferences for build-packages and stage-packages. But maybe you all have better ideas. Or would prefer to avoid getting in this mess altogether.