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 spectrum… 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