Bug#764982: Backports, where is the danger (why the FUD)
Turbo Fredriksson tu...@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 signature.asc Description: PGP signature
Bug#764982: Backports, where is the danger (why the FUD)
On Apr 19, 2015, at 10:48 PM, Paul van der Vlis wrote: Backports main is official Debian. [1] You misunderstand the announcement. … official Debian service … Notice the last word here! It say service. Not 'official _PART_ of Debian'! -- Life sucks and then you die -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/31113396-6033-4fc2-a294-43e5eabb9...@bayour.com
Bug#764982: Backports, where is the danger (why the FUD)
On Apr 20, 2015, at 9:26 AM, Philip Hands wrote: Turbo Fredriksson tu...@bayour.com writes: Good for you. Maybe it's better now, but my opinion still stands. Well, that's a jolly constructive attitude, well done. Not how I meant it, but thanx for misunderstanding. I meant that my opinion about back ports still stand. For that reason and all the others that's been mentioned. If everyone adopted such a position, we'd never get anything done now, would we? Of course we would. And so would the user(s). User opt-out is always better than forced opt-in. Right? This is the same thing. Users should know what they're in for and have to choose to enable this themselves. It should not be 'forced' upon them... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8b3d4c22-cd53-45a7-8287-9d1ea3819...@bayour.com
Re: Bug#764982: Backports, where is the danger (why the FUD)
On Mon, Apr 20, 2015 at 08:26:10AM +0100, Philip Hands wrote: 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. There is a case to me made that the documentation in non-free, especially that released uneder the GNU Free Documentation Licence with invariant parts, might be a special case here. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150420153741.ga3...@topoi.pooq.com
Bug#764982: Backports, where is the danger (why the FUD)
Op 19-04-15 om 22:00 schreef Turbo Fredriksson: If someone wants newer version, they can (should!) upgrade to the newer distribution. OR, if they're brave, use back ports. Do you mean upgrade to testing? Nobody gets a newer version by enabling backports in sources.list, you only get a newer version by using apt-get -t The problem is about packages what are NOT in stable. If you don't want backports for some reason, is easy to disable them in sources.list. Why!? Why should _I_ adapt to YOUR opinion? What makes you think that YOUR opinion is the only, correct one?? Because this is not a RC bug. Debian GNU/Linux don't enable contrib and non-free by default (or does it now, haven't checked). And yet _I_ choose to use packages from there. Why shouldn't EVERYONE be 'forced' to disable that, just to accommodate me?! Same with back ports. They're not really part of the Debian GNU/Linux distribution. Only 'main' is. The're all provided on the Debian GNU/Linux servers, but they're not the official distribution. So only 'main' should be enabled by default by the installer. Backports main is official Debian. [1] Besides, why are you still arguing about this? The decision have been made. Live with it. If you really, really think this decision is in error, then lobby for changing it in the next release. Now, the discussion is moot and pointless - suck it up. I've waited long for this. I've published about it. For me it's a big point. And then comes Cyril who removes it at the last moment... Not OK in my opinion. With regards, Paul van der Vlis. [1] https://www.debian.org/News/2010/20100905 -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553414b3.8050...@vandervlis.nl
Bug#764982: Backports, where is the danger (why the FUD)
On Apr 19, 2015, at 8:25 PM, Geert Stappers wrote: What is the danger of having backports (default) enabled? From what I've seen (when I tried it a couple of years ago), is that the back porting is quite … sloppy. If the package needs a newer lib, that is back ported as well. And the newer lib that depends on etc, etc. Eventually, you end up with such a bastardizised version of dist, it simply WILL break in mysterious ways (and it have for me, which is why is stopped using it). The correct way is, off course, to do the back port properly, make the software work with the version of the libraries etc that's already in the repo/dist. -- If something's hard to do, then it's not worth doing. - Homer Simpson -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4f8d5fd1-03cb-4662-8efb-272f4ea1c...@bayour.com
Bug#764982: Backports, where is the danger (why the FUD)
Op 19-04-15 om 20:59 schreef Turbo Fredriksson: On Apr 19, 2015, at 8:25 PM, Geert Stappers wrote: What is the danger of having backports (default) enabled? From what I've seen (when I tried it a couple of years ago), is that the back porting is quite … sloppy. If the package needs a newer lib, that is back ported as well. And the newer lib that depends on etc, etc. Eventually, you end up with such a bastardizised version of dist, it simply WILL break in mysterious ways (and it have for me, which is why is stopped using it). Did you check if it really was backports? I use backports on all machines I care about, and I never had dependency problems from backports (so far I remember). The correct way is, off course, to do the back port properly, make the software work with the version of the libraries etc that's already in the repo/dist. So far I know backports are made the correct way. This type of problems are most of time coming from other repositories, outside Debian. If you don't want backports for some reason, is easy to disable them in sources.list. With regards, Paul vand er Vlis. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55340690.2090...@vandervlis.nl
Bug#764982: Backports, where is the danger (why the FUD)
On Sun, Apr 19, 2015 at 07:35:21PM +0200, Turbo Fredriksson wrote: On Apr 19, 2015, at 7:15 PM, Cyril Brulebois wrote: Do you see that ?but?? That's exactly why it's not safe to have this turned on by default. Thank you KiBi! I defiantly don't want back ports enabled by default! _I_ don't trust them (even if the rest of the world do - I have the right to my opinion after all). And just because you, Paul, do trust them and enable them on everything, doesn't mean everyone else is comfortable with it. There is a potential risk with them (as KiBi pointed out) so having them in the file, but commented out (don't know if that was the solution, or removing them all together) seems like the most prudent option. What is the danger of having backports (default) enabled? I do see the FUD and I want to call it Fear Uncertainty and Doubt! And it is that I want to go beyond the FUD. So what is the danger that I do see yet? I also see this as a non-issue (and yet I had to voice my opinion - I must be more bored than I thought :). I wasn't bored and did read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764982#15 So now I have a nice opportunity to quote Joey Hess apt won't install newer versions from backports unless the user explicitly specifies -t $suite-backports previous in this BR Groeten Geert Stappers -- Leven en laten leven -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150419182531.gk23...@gpm.stappers.nl
Bug#764982: Backports, where is the danger (why the FUD)
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. Because of the reason I've already mentioned, but also because it's not maintained and tested as well (as KiBi said). If someone wants newer version, they can (should!) upgrade to the newer distribution. OR, if they're brave, use back ports. If you don't want backports for some reason, is easy to disable them in sources.list. Why!? Why should _I_ adapt to YOUR opinion? What makes you think that YOUR opinion is the only, correct one?? Debian GNU/Linux don't enable contrib and non-free by default (or does it now, haven't checked). And yet _I_ choose to use packages from there. Why shouldn't EVERYONE be 'forced' to disable that, just to accommodate me?! Same with back ports. They're not really part of the Debian GNU/Linux distribution. Only 'main' is. The're all provided on the Debian GNU/Linux servers, but they're not the official distribution. So only 'main' should be enabled by default by the installer. Besides, why are you still arguing about this? The decision have been made. Live with it. If you really, really think this decision is in error, then lobby for changing it in the next release. Now, the discussion is moot and pointless - suck it up. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3c904858-4711-41df-8a94-90967c86b...@bayour.com
