Turbo Fredriksson <turbo@bayour.com> writes: > On Apr 19, 2015, at 9:48 PM, Paul van der Vlis wrote: > >> Did you check if it really was back ports? > > Yes. I've been using Debian GNU/Linux since.. 'bo' or something and a DD since > '97 or so. I know what I'm doing (98% of the time :). > >> I use backports on all machines I care about, and I never had dependency >> problems from backports (so far I remember). > > Good for you. Maybe it's better now, but my opinion still stands. Well, that's a jolly constructive attitude, well done. ... > Why!? Why should _I_ adapt to YOUR opinion? What makes you think that YOUR > opinion is the only, correct one?? If everyone adopted such a position, we'd never get anything done now, would we? Personally, I very regularly enable backports, and I have no problems whatsoever with that, but perhaps the fact that I have come to that point by a conscious choice means that I'm only installing packages from backports with definite intent, and so happen to select packages that are not problematic. It had not occur ed to me that I would receive backports versions of packages missing from main, without any real warning unless I was paying close attention to the download phase. I'd suggest that using the configuration or not of backports quite a blunt tool here. It would be much better to somehow ensure that the only time that packages would be automatically installed from backports would be when upgrading packages that already came from backports, and that otherwise one would need to explicitly specify the target-release. Sadly, I don't think that we have the technology at present to make this the case, and there's no chance to add it for this release, so that seems like justification enough to back this out. I don't like that much, since that means that I continue to need to add it back in, but that's clearly better than someone being bitten by the down-side of this. An alternative that occurs to me is that we could split backports main into main and novel, say, where main is reserved for packages that do already exist in stable, and novel for packages that are being added by backports. If we did that (which could be done after the release by the backports team, so there is much less time pressure) then we could safely re-enable backports. On the other hand, that idea would need to be informed by the numbers. What proportion of backports are upgrades, rather than new packages? My subjective impression is that most of what I use backports for would fall into the 'novel' category anyway, so I'd not be saved any effort by such a change, and it would require people to understand an extra layer of complexity in order to get what they want, so really wouldn't make anyone happy. While we're at it, it would be nice to have the same "Only if I explicitly ask for it" feature for non-free (and probably contrib). I may be willing to compromise my freedom in order to get my laptop wifi working, on the basis that I could always buy a better wifi card, but that does not mean I want anything else out of non-free. This also seems to suggest that this is a more generic bug in apt. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature