Bug#596097: Please let apt reduce the amount of spam we get (was: Bug#596097: apt: Please support setting a pin of 100 from within an archive (NotAutomaticButUpdates)
2010/9/9 Carsten Hey <carsten@debian.org>:
> * David Kalnischkies [2010-09-09 10:42 +0200]:
>> 2010/9/8 Alexander Wirt <formorer@debian.org>:
>> 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
Reply to: