Bug#596097: apt: Please support setting a pin of 100 from within an archive (NotAutomaticButUpdates)
On Do, 2010-09-09 at 10:42 +0200, David Kalnischkies wrote:
> package apt
> merge 596097 186767
> thanks
>
> 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.
>
> For reference, i think you mean [0] with the docs.
> First of all, i would write your recommend one before the not recommend one,
> and i would recommend pinning by origin instead of pinning by archivename
> as people will likely forget to change it in squeeze -> wheezy transition…
>
> 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.
> 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"…
>
>
> Anyway, i have discussed it briefly a while ago already on debian-devel
> in the context of CUT, but backports was added later [1]
>
> In short: I don't see why 100 should be the default for backports.
> Even if it is currently recommend by you.
> 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 as well later on but breaks my normal experience,
> also a bunch of extensions and maybe it even requires manual handholding
> while upgrading because of dpkg-conffile changes which prevents for me the
> automated and headless upgrades i normally do in stable…
> Especially the extension-breaking thing is nothing i expect in stable.
>
> Okay, i want this upgrade at a later point, but NotAutomatic.
> What i could imagine is a package manager advertising new upgrades for
> installed packages from NotAutomatic sources, but not installing them
> automatically.
> Oh and if backports get the default 100 why not experimental, too…?
>
> What we should do is maybe write one (or more) nice preference-frontend(s)
> which help in maintaining and creating these rules as they are really
> powerful if used correctly… but unfortunately most users get them wrong…
> Any takers?
>
>
> 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…
My proposal was more on the API level, rather than the release file one.
Attaching default priorities in the API makes much more sense and is
more future proof than some flags:
NotAutomic -> DefaultPriority = 1
NotAutomaticButUpdates -> DefaultPriority = 100
This may also allow us to implement simple pinning in sources.list:
deb [priority=500] http://mymirror/debian/ sid main
(that's much more straight forward than the preferences file)
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: