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 15:25 +0200]:
> 2010/9/9 Carsten Hey <carsten@debian.org>:
> .. NotAutomatic could still be set and overruled by the new flag, even
> if it feels a bit ugly to do so…
Indeed, that seems to be a good solution for this.
> > 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…
At first there were sources.list entries for each single package (and
I think there was also a complete packages file including all packages),
later they switched to the pool structure. Before NotAutomatic was set,
just adding backports.org to the sources.list without explicit pinning
lead to having backports.org the same priority as the normal archive.
> >> 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?
I'd also assume that people care about the packages they choose to
install from backports, but I wouldn't assume that they want a specific
version but instead want a version that is newer than what's available
in stable. http://snapshot.debian.org/archive/debian-backports/...
seems to be a more appropriate URI for people who want to install
specific versions.
> >> 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 ... 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.
Good point, frontends already could do the equivalent of "apt-get
--no-list-cleanup -o Dir::Etc::sourceparts=/dev/null -o
Dir::Etc::sourcelist=<(grep -hs security /etc/apt/sources.list
/etc/apt/sources.list.d/*)" to upgrade only specific parts (they would
also need to use a different Dir::Cache). This would be quite hackish
but good enough for a proof of concept. To make it more mature, apt
could use optional tags in Release files and provide an API to access
them or filter for specific ones. Anyway, this seems to be an unrelated
problem.
Only upgrading specific repositories like security sounds like a feature
that could be useful for apt's cronjob, if it is not already implemented
there (I think I saw such a "update only security" feature somewhere).
> 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…
apt-clone, which creates zfs snapshots before upgrading, could be useful
for him, but this would require a kernel with zfs support. He could
also adapt it to use lvm ;)
> 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.
This explanation is a lot easier to understand than the man page :)
> 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)
The problem with setting DefaultRelease is that there are many ways to
install Debian, only one of those is using the Debian-Installer; besides
this, users should be able to upgrade to newer releases without having
disadvantages like backports not working like they should out of the
box.
Regards
Carsten
Reply to: