[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: Moving from Testing to Stable + Backports
From:       Andrei POPESCU <andreimpopescu () gmail ! com>
Date:       2021-08-31 8:58:24
Message-ID: 20210831085824.kcrgydwxjjsjoygw () acr13 ! nuvreauspam
[Download RAW message or body]


On Lu, 16 aug 21, 05:10:36, Michael Grant wrote:
> I've been using Testing for about a decade now with very few problems.
> But now I'm moving to Stable.  Just wanted to mae sure I'm doing this
> right.
> 
> I last updated using Testing on the friday, then the release happened
> on saturday.  I changed my sources.list as below, did an apt update;
> apt upgrade, and uncerimoniously there were no updates to install, my
> system was already on bullseye.  Easy.

Ok.
 
> My intention is that when I upgrade or install something from now on,
> I want to take the latest most resonable version of it.

Depends very much on your definition of "reasonable".

> If there's a security update, I want that version first.

Ok.

> Normally if I install something, it should come from stable.  However,
> if there's a backport of that thing, I prioritize the newer backport
> instead.

Packages in backports, by definition, should bring in newer features, so 
this kind of makes sense.

> But what if something got updated from backports and then later
> there's a security update for it in bullseye-security. Since I
> prioritize bullseye-security, what's going to happen?  Is it going to
> reinstall a lower version number from bullseye-security?

This depends a lot on the particular package. If you're lucky the 
security issue affects only the version in stable and you are safe to 
stay with the backports version.

If not, you will have to wait for the security issue to be fixed in the 
backports version, timeline unknown.

> Lastly, I want to be able to manually install things from testing and
> from experimental.

Here be dragons!
 
> ----preferences----
> Package: *
> Pin: release a=bullseye-security
> Pin-Priority: 1000
> 
> Package: *
> Pin: release a=bullseye-backports
> Pin-Priority: 950
> 
> Package: *
> Pin: release a=bullseye
> Pin-Priority: 900
> 
> Package: *
> Pin: release a=testing
> Pin-Priority: 250
> 
> Package: *
> Pin: release a=experimental
> Pin-Priority: 1
 
In my opinion, the most important thing to remember about pin priorities 
is that APT may install from or consider for upgrade *any* source with 
priority between 1 and 1000, even without a specific request to do so.

The exact priorities will have an influence on that, but the outcome is 
much less predictable than you seem to expect it.

In any case, if you really, really want to go this route you might want 
to start using aptitude's interactive interface instead, because it can 
show you the release of each package before you trigger the 
install/upgrade.

In addition to that, you should consider that stable-backports and 
experimental are meant to be used only for explicitly selected packages.

E.g. package bar in -backports may also need a backported libfoo, but 
package baz works fine (and is built against) libfoo from stable. What 
happens if you install both bar and baz from -backports? Nobody is 
actually testing this, so if it's an issue you'll be the one to find 
out.

In addition to that, experimental is basically an easy method for 
developers to upload a package (considering also that Debian doesn't 
have Ubuntu's PPAs). These may be anything from throw-away experiments 
that are long forgotten[1] up to newer, release-quality packages during 
the freeze.

The decision to install *anything* from experimental and backports 
should be considered carefully and for each individual package. Even the 
default priorities of 1 and 100 respectively can be dangerous in 
particular circumstances, because APT will pull packages from there 
without asking if these are the *only* sources with that package.


[1] It's entirely possible that a particular package in experimental was 
built against unstable from 10 years ago. There is no automatic cleanup 
of experimental.

Hope this explains,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]