On Mon, Nov 30, 2015 at 06:11:10PM +0100, Cyril Brulebois wrote: > Charles Plessy <plessy@debian.org> (2015-11-30): > > However, there is an exception: when a package is in the backports suite but > > not in the base suite, it will be installed by "apt install foo" without the > > need to select the backports suite. For this reason, jessie-backports has not > > been added to the default sources.list in new installations. > > (<https://bugs.debian.org/764982>) […] > Teaching apt to ask explicitly in such a case would make the problem go > away as far as I'm concerned, and I'd be happy to have stable-backports > enabled through apt-setup. I'm therefore adding apt developers to the > loop to get their opinion (and debian-boot@). APT is installing packages based on the pin value. NotAutomatic and ButAutomaticUpgrades do effect only upgrades in practice as they switch the default value of 500 (or 990 if its the default release) to 1 or 100 respectively. All of these choices are > 0 and hence valid candidates, it is just that if a package is in your preferred release (here stable) this package has the highest pin and therefore you need an explicit request to change the candidate to lesser pinned sources. In other words: If you have experimental sources on your stable system, packages new in experimental will be automatically installed, too, if requested without any force needed (it won't be upgraded through as installed is pinned 100 which is higher than 1). Everything else would be against how pinning works – and its like that for 17 years now, so it can't be all bad – aka: feature. I don't think this is wrong, given that you have this source enabled and you want that package installed, so not offering this solution would be a disservice. Pretty much the same thing as with non-free. The problem is "just" that you aren't told all details which could influence your decision of accepting or denying the solution in a very visible way upfront with apt (aptitude cui is better in this regard I guess). I have longterm plans to change this and the code slowly moves in this diection, but to make that fly there is a bunch of stuff still to do. A bigger part is on our next-up list: Merging back (the better parts of) aptitudes pattern system. With that in place I envision being able to configure package listings as well as configure the display of matching packages in listings which would – assuming we could agree on some for most people sensible defaults which isn't going to be trivial – solve this eventually… So, then does that happen? Lets say it this way: Roughly six years ago I joined the apt team with this very simple idea… rapid development of features is a bit harder than I would like if the team is cronically understaffed. Personally, I am in the "enable backports by default" camp as I believe that most people who issue a "apt install foo" want foo installed and do not care enough about stable vs. backports to say 'no' to the solution even IF they would know at the right moment that foo comes from backports (same for non-free) – but I can perfectly understand that some want to hold that off until everyone actually has the information at the right moment. [That is not to say that the treatment by a user doesn't change if she knows – I prefer potentially buggy open firmware over closed one for example and given the choice of cake via backports or no cake, I will opt for backports accepting less service than stable, but if apt would hide this choice behind an error I would just get the impression that the system is making this needlessly difficult – after all, far more dangerous solutions like removing the entire desktop environment is purposed without additional loop to jump through, too] Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature