On Tue, Jan 12, 2016 at 12:52:04PM +0100, Martin Zobel-Helas wrote: > Hi Charles, > > On Mon Dec 28, 2015 at 23:19:30 +0900, Charles Plessy wrote: > > In conclusion: > > > > We are not going to enable backports by default in the short term, but > > I hope that some readers, like me, strenghtened their understanding on > > how APT works. > > First of all, thank you very much for this excellent summary. > > How about the following idea: In case we are not able to find a > technical solution for this for the Debian Stretch release, we encourage > cloud providers to offer two images, one with backports enabled and one > without backports? For the backports-enabled images we then could ask > them to add a disclaimer explaining the technical problem.
I have two possible solutions: (1) Changing the pinning defaults so NEW packages from NotAutomatic repositories are pinned to -1 by default instead of 1/100. (2) Changing the output. David likes (2), but it really makes no sense overall, as it does not affect other frontends at all. (1) is implemented right now in http://anonscm.debian.org/cgit/apt/apt.git/commit/?h=feature/noinstall-notautomic&id=cf4761eea9e9f6f17e90d1d1e9c369087de5efd0 This will make some frontends like aptitude potentially do wrong stuff but it's the only way to make sure dumb frontends could not automatically install a package. On the other hand, some frontends could not install any package from backports at all (/me looks at gnome-software). So I'm not sure I want a technical solution. (1) breaks stuff and use cases and (2) gives us some assurance, but only for APT and not for dumb frontends. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you.