2010/9/9 Carsten Hey <[email protected]>: > * David Kalnischkies [2010-09-09 10:42 +0200]: >> 2010/9/8 Alexander Wirt <[email protected]>: >> Beside that you will shock each lenny to squeeze changer which doesn't >> read the news… or does make an upgrade with apt/lenny which doesn't >> understand the new flag and therefore treats backports as normal >> archive: "Wonderful mix of version do you have on your system, sir"… > > Computers of people who don't read nor understand things become spam > bots or similar. We should provide sane defaults for all, and > especially those, people. Not installing security updates unless > explicitly requested by the user is all but sane.
I mean that apt/lenny will not recognize the new flag and therefore treat the archive as "normal" archive with pin 500, which will be fun if no target release is set. But forgot the argument itself, NotAutomatic could still be set and overruled by the new flag, even if it feels a bit ugly to do so… > Five years ago, when I mentioned DefaultPriority in #186767 and talked > about the possible usage at backports.org, it was pinned to 500 by > default (not NotAutomatic). I'm not aware that anybody complained when > NotAutomatic was enabled for backports.org some years ago. I am around for a bit more than a year or so, so my backlog doesn't reach far enough, but it could be possible that a targetrelease was set in the past by the installer or so which would have the same result as setting the archive to 100 without a targetrelease… > If we (or rather the backport.debian.org ftpmasters, I'm just trying to > convince you to provide the apt feature that is a prerequisite for this) No need to convenience me (as long as you don't want to trick me into writing the patch ;) ) -- Thats one of the good characteristics of being a nobody with no rights, i am free to say no without harming anyone. :) Better use your energy "against" Julian or Michael. > want to switch to automatic updates, what would a better time to do this > than with the switch from backports.org to backports.debian.org? Sure its a good point, i just want to say that you will still have users who simply switch the url (at a much later point as the service will be continued at this place as far as i read) without reading news… >> As a stable user i might want to get upgrades for the iceweasel >> 3.6-series through backports, but what i don't want is an iceweasel >> 4.0 upgrade which will end-up in backports ... Maybe its just my wrong assumption and my unsophistication which tricks me into thinking that people using backports actually care for this specific software they have installed through it. Otherwise they would just stick to the stable version, doesn't they? >> Especially the extension-breaking thing is nothing i expect in stable. > > Backports is not about stable, it is about packages from testing or in > rare cases from unstable compiled for stable. I use iceweasel as an example here as it happened this way to me with a friend who flamed me to death that the "oh soo stable debian" "suddenly" disabled a bunch of his beloved extensions after an upgrade. He had read somewhere on the internet that a new firefox version is available fixing a bunch of bugs, kindly remembered that i told him iceweasel=firefox (at least for his needs) and maybe even remembered that he enabled and uses backport for it to use a new ubercool-feature but didn't looked closely enough to notice what he suspected to be a security upgrade is really the next beta-release-candidate… Sure, he should have looked closer and sure he needs to upgrade at some point - i am just saying that it is confusing that both minor-you- don't-need-to-care-about updates as well as major-new-groundbreaking- version updates are coming through the same channel without a good visible difference. That is a problem in unstable and testing (and therefore CUT) too so nothing really new, but it lead my friend to a point to step back from regular headless upgrades even in stable and to replacing them by irregular "if i have time to fix the maybe incoming problems by new major versions" upgrades which normally results in: "I haven't upgraded for 6 months now…" I am not sure if that will be any help in reducing the amount of spam… (And yes, i know that iceweasel is also a perfect example to prove me wrong as most bugs are fixed in xulrunner and co which no real user cares about so these upgrades would be unnoticed if not done automatic… which is btw also not very well communicated to the user) > I'm not sure if 100 or 101 would be the correct priority, but given that > DefaultRelease and -t both pin to 990 and should do the right thing when > used together, it looks like 100 could be sufficient. 100 and 101 makes no difference expect that a 101 repro will have preferences over one with 100. But as i said above, if the DefaultRelease is set you could even set the archive to 500 and you will have the same effect as with 100 as every value 100 => x > 500 has the same effect without DefaultRelease and even 100 => x > 990 if its set. 1 is notautomatic, 100 is the currently installed, 500 each archive which is not notautomatic and not the default release and 990 archives which are the default release (if not pinned otherwise of course). Pinning is as easy as finding the version with the highest number attached above or equal to the currently installed version (at least pin 100, but likely the pin from the archive this version comes from). Exception: x >= 1000 will overrule everything even if below installed version. So, maybe the solution to this thread is even to set a defaultrelease somewhere and to drop the notautomatic bit in backports instead of introducing a new flag… beside that failing to set the defaultrelease will give very bad results to the users… (= a mixed stable/backports system) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
