[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backports installed without prompt if not in base suite: bug or feature ?

(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

Reply to: