[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 ?

On Tue, Dec 01, 2015 at 05:00:47PM +0100, Rhonda D'Vine wrote:
> * David Kalnischkies <david@kalnischkies.de> [2015-11-30 22:22:08 CET]:
> > 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 really consider the reasoning of "it always has been that way" kinda
> disturbing, frankly spoken.  It has been used in very bad areas over the
> history of human development, please don't use it.  That's not really an
> argument.

All what I was trying to say is that the apt_preferences behaviour
I explaining in this mail isn't a new invention, but exists since the
beginning of apt in this way as a core design principle (in my eye),
using the "it can't be all bad" as a reference to the fact that apt is
still used while a lot of things with different designs fell out of
favour because decisions in opensource aren't made by big white guys
with power to have you killed if you look in the wrong direction, but by
users who simply either use it or not.

I wasn't advocating $very-bad-area because humanity did that for
centuries and, frankly spoken, I am quite shocked its even suggested
I would be – not only because that offends me, but it also suggests the
work needed to stop $very-bad-area is even only remotely comparable to
changing a piece of software – after all a single person can replace all
of apt completely in a few days (q.e.d.: cupt) without fearing any
negative consequences (beside users actually using it perhaps).

(yes, I wrote that section last as reading what I had to respond to
alone made me super angry already and I didn't want to paint the whole
mail in this emotion)

> > I don't think this is wrong, given that you have this source enabled
> > you want that package installed, so not offering this solution would be
> > a disservice. Pretty much the same thing as with non-free.
>  And with my backports hat on I consider the comparison of backports
> with non-free quite disrespectful, too ...

I am sorry.

I was using non-free (as it was established in the context already) as
a means to broaden the view. Not in the "backport or non-free, its all
the same crap" sense, but in the "I see little difference in the need to
tell the user that a package comes from backports compared to that it
comes from non-free given that both aren't the default source". An
earlier draft was talking about experimental, various third-party
repositories, future bikesheds and what have you, but I cut that out too
reduce length and so ended up using only backports and non-free as the
probably most relatable examples on opposite sites of the sources

As it is now obvious to me I cut so much, that its actually easy to get
the wrong idea… so, again, I am sorry, it wasn't meant that way.

> > 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)
>  Again - please do *not* compare backports with non-free.  And that you
> consider people not to care is a fair bit disturbing.  The objection to
> putting backports into the default install should be reason enough for
> you that there are people who *do* care and you shouldn't disregard
> their opinion with a statement of people don't care anyway.

I was saying "personally", I mentioned camp implying that there is (at
least) another, words like "believe" and "most" aren't really very
definitiv words and further down the line I even explicitly acknowledged
the status quo as different and that I can agree with it even through
I have a different opinion. I don't think that qualifies as disregarding
opinions and don't caring, but I will assume that you only said that as
you were expecting me to be like it after reading my previous statements
(incorrectly, by my own fault).

The whole paragraph was meant as full disclosure to avoid the inherent
"display problem" of coming from a certain view point (aka source), but
no indication of this (and yes, this is a "pun").

So, with that said, lets try again:

I don't think its a good idea to change the behaviour I described
explicitly in the last mail as plenty of users (including me) and tools
actually depend on and like this behaviour. It is so natural that even
the experimental buildds are using it (via aptitude or aspcud now) in
that they take the liberty of using package versions from less preferred
(declared via means of apt_preferences ex- or implicitly) sources to
provide dependency resolutions a user can accept or not instead of
displaying an error. Multiple bugreports against apt in fact show that
users want this to happen more instead of less.

Changing the preferences behaviour is beside a multi-year process
changing a core design element which shouldn't be done at a whim to not
alienate people who actually liked/expected that behaviour and have
chosen to use apt because of that. Further, changing the behaviour of
the NoAutomatic flag e.g. effects experimental and backports, but
doesn't non-free and plenty of other sources which I (as a user) will
not understand why they aren't dealt with in the same way as I want to
know if a package comes from backports just as much as I want to know if
it comes from non-free – a knowledge which can potentially guide me in
accepting or denying the solution offered to me.

I don't have this information available (in an easy way) at the moment,
which is what I consider the bug here – not that the solution is offered
at all, given that I want a package manager to offer me solution(s) as
if I wanted to invent my own, I wouldn't need a package manager.

So instead of requiring me to perform manual dependency resolution by
explicit requests calculate the best thing you can come up with and show
it to me and I will decide if that is good enough for me or not based on
my opinion and not on what some Debian deities decided would be best for
me without actually knowing me.

Excursion: Consider a package moving from main to contrib or right about
any package crossing a source boundary: No amount of apt_preferences is
going to help you prevent this from happening in the general case.  That
is something a user wants to know to decide how to proceed as there is
no one-size-fits-all solution here everyone will agree to.

Personally, I would enable backports by default, if all it depends on is
this "potentially installs backports packages if a user requests the
installation of a package which isn't in stable"¹ as that is
a relatively unlikely situation – given that I have heard about this
package somehow enough to want to install it, I probably found also
a remark about it being in backports – and at least in my view a user
who wants apt to install foo is likely to accept a solution involving
backports (if that is the only possible choice) as the alternative is
not having foo. BUT I do understand if the people who actually can make
this decision of enabling backports or not have a different opinion and
instead want to wait for apt giving an explicit hint about what is going
to happen to the user before she presses yes (which is what I would
prefer, too, but can't promise to happen soon).

Feel free to exchange backports with non-free, a random third-party
repository, a random bikeshed or whatever and evaluate your choices.
Probably you can identify a threshold for a solution to be "good enough
for a yes" vs. a "bad enough that I don't want this foo anymore".

The threshold of solution acceptances will vary from user to user
depending on the source, so having this information is important, but at
least I would assume that nobody wants to see an error message requiring
them to figure out that the problem is that a package from foobar source
would be needed you have therefore to explicitly request on the
commandline – repeatingly until you have figured out a solution by hand.

Best regards

David Kalnischkies, who speaks as a single user who also happens to
write patches for apt who are accepted at times. Other users and/or
developers might have a different opinion.

¹ there is another situation: A package you installed from e.g.
backports requires in a new version a new package only available in
backports. I will leave it as an exercise to the reader to figure out
why I might not envision this to be a giant problem either and why that
is also better solved by a proper display than an error message.

Attachment: signature.asc
Description: PGP signature

Reply to: