On Sb, 04 oct 14, 16:44:17, Mark Carroll wrote: > Andrei POPESCU <andreimpope...@gmail.com> writes: > > On Sb, 23 aug 14, 13:43:50, Mark Carroll wrote: > >> > >> Package: * > >> Pin: release a=testing > >> Pin-Priority: 50 > >> > >> Package: * > >> Pin: release a=unstable > >> Pin-Priority: 40 > > > > This will make both testing and unstable have a lower priority than > > installed packages. In practice this means you will *never* receive > > updates to packages you installed from testing or unstable. Not even > > security updates. > > Yes, I want to give chance for stable updates and suchlike to catch up > with them over time: I generally don't want to be using packages from > testing and unstable unless I have to, and I'd like them not to stay > ahead in the longer term. Security updates aren't an issue because I > subscribe to debian-security-announce and manually make sure that > anything applicable does get updated, and so far I don't think that's > been anything I actually had from later than "stable". The only time one could say stable is "catching up to testing" is the moment of a stable release, but even then, it's not quite accurate since the current testing *becomes* stable, the next testing is started as a "copy" of stable[1] and testing migration is enabled (again) to allow packages from unstable to migrate to it.
But as long as you watch for security updates you should be fine. [1] in practice each package version exists only once in the pool > (Annoyingly, apt seems to get upset if I want to force the later > packages into trying to use older dependencies to see if they work well > enough, so I can end up pulling in more later packages than I want to, > but it tends to work well enough to uncompress the package and tweak > its metadata and install that adjusted version instead.) Ugh! Did you consider local backports instead? > > If unstable has to be used (are you sure? packages should migrate to > > testing within days anyway) then yes, it makes sense to pin it to > > something lower than 100. > > I guess they don't always so quickly, because I do try the "testing" > version before the even later ones, but I certainly do sometimes end up > having to use the "unstable" or, admittedly rarely, experimental. My > guess is that "unstable" might be for a couple of reasons: something it > interacts with, some service on the Internet or whatever, changed, and > the package is just suddenly unexpectedly broken without a patch that > quickly appeared upstream; or, I had a bug where the package maintainer > didn't really care unless I could confirm it also occurs with the > latest. Actually, fairly often I have software that just really doesn't > work so well, and I try progressively later versions to see if I am > lucky enough to hit one that has the bug or annoyance actually fixed, > which of course sometimes has me go all the way before finding it isn't. Have you considered using chroots instead? > > Beware though that the package will not be updated until testing has a > > higher version. This is especially important in case of security > > upgrades. > > I actually usually assume that "testing" doesn't much enjoy security > upgrades: they'll hit "stable" and "unstable" first, so that's partly > why I use the mailing list to help make sure I'm on top of things. My > system's core services are pretty much all from "stable" anyway, it's > usually just the occasional utility or connector that isn't. Security fixes for testing usually go through unstable, but with reduced migration times (2 days?). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt
signature.asc
Description: Digital signature
