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)
* David Kalnischkies [2010-09-09 10:42 +0200]:
> 2010/9/8 Alexander Wirt <formorer@debian.org>:
> > for backports.debian.org we use the NotAutomatic Flag to prevent
> > users from installing every backport. Unfortunatly that has the
> > drawback of preventing updates from installed backports. Even if our
> > docs trys to force users of pinning backports to 100 several don't
> > read the docs or don't understand it.
>
> Further more, you could only use this flag for squeeze, not for lenny
> as you otherwise break all existing uses on flagday and even squeeze
> is a bit flacky as it already exists and could therefore be already
> used.
Backports ftpmaster is aware that it can not be used for Lenny and
squeeze-bpo will not exist (or rather contain any package) before
Squeeze is released. If it will be enabled for Squeeze it will be
enabled before the very first package hits squeeze-bpo and it will not
be enabled for lenny-bpo.
> 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.
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.
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)
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?
> 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 ...
I wish you much fun with the root kits you'll get ;)
But seriously, if you (as the stable use you claim to be in this
example, not as the apt maintainer you are, who of course knows how to
configure apt) know what you are doing and read security lists you'll
also be able to find out how to pin backports.debian.org repositories in
a way you like.
To hold single packages there are also dpkg holds used by apt and
aptitude holds used by aptitude. One could argue that dpkg holds are
not easy to use ... once upon a time there was dpkg-hold and dpkg-unhold
(I'm not sure if there was ever more than its man pages in Debian) to
ease holding packages, nowadays one could easily (code that could be
adapted exists) write a simple dialog or zenity based frontend to do
manage dpkg-holds. Such a frontend might possibly also be part of
synaptic already.
> 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.
> Oh and if backports get the default 100 why not experimental, too…?
Such things should be discussed with and decided by ftpmaster. One
reason not to enable it is that experimental is supposed to contain
experimental software that is possibly not suitable for a stable
release, on the other side, backports.org is supposed to contain
software in release quality (as far it can be judged by the maintainer,
since it has not gained the long testing stable packages have). Due
this possible breakage of experimental software upgrading might not
always be the right thing to do and especially experimental users should
know what they do and be aware of security issues. Besides broken
software there are also things like aptitude not being updated to the
latest apt ABI which could lead to aptitude removing itself (btdt)
- users who think aptitude is more than a remote changelog pager might
miss this bloated wget + less wrapper.
> btw: As said in the referred thread i don't like the free form
> Default-Pin for its additional pin-war potential. Its crazy enough
> that some archives "fight" with epochs against each other…
Agreed, the pin-war potential is the reason why I don't think
Default{Priority,Pin} should be implemented, anymore. If it really
would be implemented it should be restricted to a range of allowed
priorities, e.g., 1 and 200 to 300, to let the other priorities to be
used by the system administrator.
NotAutomaticButUpdates would not have such a pin war potential.
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.
Regards
Carsten
Reply to: