(see the other mail for more on this topic and also hopefully as a clearup of what was meant initially; just picking some semi-unique element here) On Tue, Dec 01, 2015 at 03:39:25PM +0100, Philip Hands wrote: > David Kalnischkies <david@kalnischkies.de> writes: > > 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) > > I'd say that non-free is very different from backports in this context. > > One might enable non-free solely to get a wifi driver, and want nothing > else from it. One might disagree with the Debian position on GFDL and > want all the GNU documentation, while wanting nothing non-free. Which is exactly how some use backports: only wanting a very specific package, not the whole zoo. Its also how the majority of sources a user can have are supposed to operate as pretty much only "Debian my current release main" can be considered a catch all while all the rest was likely added to get this or that package only. > Such users are going to want updates to any of those packages, but > they're not going to want to get another single non-free package unless > they explicitly ask for it (with -t non-free or foo/non-free) The solution for those users is pinning packages from their undesired source to -1 (or lower, which translates exactly to "this is never a candidate") and pin specific packages (those which they have installed from there) to 100 (or slightly higher). That is cumbersome to work with, but it works. Its also a surefire way of running into miles long error messages you have to be a wizard for to decrypt. > Assuming we can make non-free behave in this way (so that upgrades are > automatic, but new installations are only by request), then it seems > possible that some people would also appreciate that feature in > backports. I already described that this is impossible with preferences alone and you can read all about it in the manpage for it: apt_preferences (Reading it carefully you will realize that this something most people describe as "upgrade" doesn't exist, but is just an happy accident of how pin values are chosen as by the time a new version is online nobody knows anymore where the old version came from…) I guess we could come up with some hardcoded logic in apt, but that wouldn't work for everything else be it aptitude, packagekit or whatever people use nowadays to install stuff and I don't see why backport or non-free would be special snowflakes here given that many users have many sources they only want very specific packages from. I further guess that we could hardcode a logic in libapt similar to the one described above with -1 and 100 pins, but that breaks tools which are supposed to flip to less preferred sources if needed like experimental buildds for example (see next), gives you the "perks" mentioned above and would be an all around stranger in an already complicated topic code and documentation wise. > If nothing else, having it as a configuration option that we can enable > by default would allow the d-i team to enable backports with confidence > knowing that this would not result in any surprised users. This imagined user isn't surprised that she gets a solution offered which includes packages from a less preferred source – aptitude does this all the time and was therefore also used to resolve dependencies on experimental buildds (now its apt with an external solver which has the same properties). In fact, we have plenty of bugreports detailing that users are surprised that apt is /NOT/ taking a package from a less desireable source. The external solver protocol for APT (EDSP) has an option to free a resolver from even more preferences concerns as I fought hard to not have it as the default… Your imagined user is surprised that she isn't told about such things before hand in a simple way (you can look for yourself with show or policy, or look at the download process, but that isn't simple and the later a bit late). That is a display problem, which as said, we are slowly but steadily working on in apt. Solving this with an option (our solution to everything) or just not enabling it by default isn't a solution: A user will just disable the option or enable the repository and will still be surprised by this. Even if you call the option I::want::apt::to::surprise::me=true. (People are repeatly told that recommends shouldn't be disabled, still way too many people do it and complain loudly if something breaks as that is a one time action with gets you into trouble only many months later if at all – and broken recommends are actually displayed…) Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature