Re: Moving from Testing to Stable + Backports
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 Description: PGP signature
Re: Moving from Testing to Stable + Backports
On Tue 17 Aug 2021 at 16:19:48 (+0100), Brian wrote: > On Tue 17 Aug 2021 at 10:43:29 -0400, Michael Grant wrote: > > I included Experimental which probably was a mistake and I probably > > meant Unstable. (I can see Greg rolling his eyes...) > > > > Here's a blog post I was looking at: https://rabexc.org/posts/apt-config > > > > This is very close, if not exactly, what I want to do. I'm very aware > > about mixing releases. If you ever do this, you need to be very > > careful not to suck in a ton of dependencies. Greg is correct, you > > can at the click of a key unwittingly install so many dependencies > > that your system becomes that release. Where I would part company with that blog's philosophy is at "fallback to stable first, unstable second, and experimental last". Experimental as a fallback! The problem with following a blog is that it assumes you have a technical competence comparable with the author, and the confidence to go with it. I took a look at another rabexc story there, where they had a failing SSD that caused running dpkg to fail, but they needed smartmontools to examine the disk. So they just created /var/cache/apt in memory, downloadloaded and unpacked smartmontools, and ran the binary from there, without breaking sweat. Not for the faint of heart. Cheers, David.
Re: Moving from Testing to Stable + Backports
On Tue 17 Aug 2021 at 10:43:29 -0400, Michael Grant wrote: > > some people have different goals than i. > > You're correct. Though I do have a primary goal to have a stable > system, I sometimes (albeit it's rare) I need to install package > that's not in stable, or I need some feature from a more recent > version of something which is why backports is important to me. I wonder what you mean by "stable" system? In a Debian context it means "unchanging". You cannot have a stable system with a testing or unstable line in sources.list. The best-effort backports should be OK. All the packages there are built on stable. A single package from testing or unstable may be OK, but if it brings in other packages I'd think twice about it, especially if it involves the infrastructure of the system. > Up to now, I have been running Testing which has served me pretty > well. I've been convinced by discussion here to move to Stable + > Backports. Sounds like a good plan. > I included Experimental which probably was a mistake and I probably > meant Unstable. (I can see Greg rolling his eyes...) > > Here's a blog post I was looking at: https://rabexc.org/posts/apt-config > > This is very close, if not exactly, what I want to do. I'm very aware > about mixing releases. If you ever do this, you need to be very > careful not to suck in a ton of dependencies. Greg is correct, you > can at the click of a key unwittingly install so many dependencies > that your system becomes that release. You really appear to have it sorted now. -- Brian.
Re: Moving from Testing to Stable + Backports
> some people have different goals than i. You're correct. Though I do have a primary goal to have a stable system, I sometimes (albeit it's rare) I need to install package that's not in stable, or I need some feature from a more recent version of something which is why backports is important to me. Up to now, I have been running Testing which has served me pretty well. I've been convinced by discussion here to move to Stable + Backports. I included Experimental which probably was a mistake and I probably meant Unstable. (I can see Greg rolling his eyes...) Here's a blog post I was looking at: https://rabexc.org/posts/apt-config This is very close, if not exactly, what I want to do. I'm very aware about mixing releases. If you ever do this, you need to be very careful not to suck in a ton of dependencies. Greg is correct, you can at the click of a key unwittingly install so many dependencies that your system becomes that release. signature.asc Description: PGP signature
Re: Moving from Testing to Stable + Backports
Greg Wooledge wrote: > On Mon, Aug 16, 2021 at 03:07:06PM -0400, songbird wrote: >> Greg Wooledge wrote: >> ... >> >> deb http://deb.debian.org/debian/ experimental main contrib non-free >> >> deb-src http://deb.debian.org/debian/ experimental main contrib non-free >> > >> > And this is just stupid. Remove this immediately. >> >> some of us don't mind trying out more recent versions of >> some packages: > > You CANNOT install binary packages from experimental on stable safely. > It's nonsensical. i know what you mean, but at times it really isn't for certain situations. i'm not someone who will tell someone else what they can and cannot do with their own system. some people have different goals than i. songbird
Re: Moving from Testing to Stable + Backports
On Tue, Aug 17, 2021 at 08:44:49AM +0200, to...@tuxteam.de wrote:
> On Mon, Aug 16, 2021 at 08:27:18PM -0400, Greg Wooledge wrote:
> > https://wiki.debian.org/DontBreakDebian
>
> Yes. We know that one.
Do we? Do we really?
Then why do people keep violating it so flagrantly?
> Whoever is mixing suites should have
> read that. And be prepared to cope with some or other degree
> of brokenness.
No. They shouldn't do it. At all!
It's not OK to mix binary ("deb") repositories for stable and anything
newer than stable if your end goal is, and I quote, "Moving from Testing
to Stable + Backports".
If you mix binary repositories, then you are running whichever release
has the highest-numbered packages out of your set of binary repositories.
This means: if you mix binary repositories for stable and testing, you
are running testing. You are NOT running "stable with a bit of testing
here and there". You're running testing. Full stop.
If you try to complicate your life by adding pinning, this does NOT mean
you are running "stable with a bit of testing". No. It means you're
running a BROKEN version of testing. When it comes crashing down around
you, we will continue to tell you to please Don't Break Debian.
> Reminding people of that seems OK, but yelling at them in
> public... hm.
If I don't "yell", they don't listen.
Re: Moving from Testing to Stable + Backports
On Mon, Aug 16, 2021 at 08:27:18PM -0400, Greg Wooledge wrote: > On Mon, Aug 16, 2021 at 03:07:06PM -0400, songbird wrote: > > Greg Wooledge wrote: > > ... > > >> deb http://deb.debian.org/debian/ experimental main contrib > > >> non-free > > >> deb-src http://deb.debian.org/debian/ experimental main contrib > > >> non-free > > > > > > And this is just stupid. Remove this immediately. > > > > some of us don't mind trying out more recent versions of > > some packages: > > You CANNOT install binary packages from experimental on stable safely. > It's nonsensical. Greg, I appreciate your wisdom, really [1]. But I sometimes get the impression that you take your POV too absolutely. And shouting doesn't help, either. > https://wiki.debian.org/DontBreakDebian Yes. We know that one. Whoever is mixing suites should have read that. And be prepared to cope with some or other degree of brokenness. Reminding people of that seems OK, but yelling at them in public... hm. Cheers [1] No sarcasm. Your bash guide is outstanding! - t signature.asc Description: Digital signature
Re: Moving from Testing to Stable + Backports
On Mon, Aug 16, 2021 at 03:07:06PM -0400, songbird wrote: > Greg Wooledge wrote: > ... > >> deb http://deb.debian.org/debian/ experimental main contrib non-free > >> deb-src http://deb.debian.org/debian/ experimental main contrib non-free > > > > And this is just stupid. Remove this immediately. > > some of us don't mind trying out more recent versions of > some packages: You CANNOT install binary packages from experimental on stable safely. It's nonsensical. https://wiki.debian.org/DontBreakDebian Experimental may be mixed with UNSTABLE if you are brave AND clueful. It may NOT be mixed with stable. I don't know how you can possibly think otherwise. https://wiki.debian.org/DontBreakDebian
Re: Moving from Testing to Stable + Backports
Greg Wooledge wrote: ... >> deb http://deb.debian.org/debian/ experimental main contrib non-free >> deb-src http://deb.debian.org/debian/ experimental main contrib non-free > > And this is just stupid. Remove this immediately. some of us don't mind trying out more recent versions of some packages: frex: uname -a Linux ant 5.13.0-trunk-amd64 #1 SMP Debian 5.13.9-1~exp2 (2021-08-10) x86_64 GNU/Linux it's not stupid, it's just one way of doing things. songbird
Re: Moving from Testing to Stable + Backports
On Mon, Aug 16, 2021 at 08:29:36AM -0400, Michael Grant wrote: > Ok I added bullseye-updates now, thanks. > > What priority should I apply to bullseye-update in preferences? Get rid of ALL of that crap, if you are running stable. No pinning. No preferences. (Backports are automatically pinned, so you don't have to do anything.) You run stable. That's it. unicorn:~$ cat /etc/apt/sources.list deb http://ftp.us.debian.org/debian bullseye main contrib non-free deb http://security.debian.org/debian-security bullseye-security main contrib non-free deb http://ftp.us.debian.org/debian bullseye-updates main contrib non-free deb-src http://ftp.us.debian.org/debian unstable main unicorn:~$ ls /etc/apt/preferences.d/ unicorn:~$ deb-src lines are OK, because they allow you to build your own backports if need be. I haven't had to build one in a while, certainly not since bullseye was released, so at the moment that deb-src line isn't doing anything for me. I should probably go comment it out now.
Re: Moving from Testing to Stable + Backports
> You're missing the "bullseye-updates" repository, but it's optional. If > the lines above were the only lines in your sources.list, you would be > doing it correctly. > > Bullseye-backports is also optional, and there probably aren't any yet. > And even when there are some, there's no guarantee that you'll need them. > Personally, I prefer to leave the -backports out of it unless and until > I actually need one. But if you want to bring it in proactively, that's > acceptable. > > > deb http://deb.debian.org/debian/ testing main contrib non-free > > deb-src http://deb.debian.org/debian/ testing main contrib non-free > > *THIS*, however, is wrong. > > With testing lines added to your sources.list, you are not running stable > (bullseye) any longer. You are still running testing, just with a > fallback option to retrieve bullseye packages as well. > > > deb http://deb.debian.org/debian/ experimental main contrib non-free > > deb-src http://deb.debian.org/debian/ experimental main contrib non-free > > And this is just stupid. Remove this immediately. > Ok I added bullseye-updates now, thanks. What priority should I apply to bullseye-update in preferences? With respect to having testing and experimental in the sources.list, I had testing prioritized at 250 and experimental at 1. The idea was that if some new package came along that I wanted to mess with, I could install it easily but if the there was a package belonging to bullseye, it would be installed there by priority. I am vigilant not to install things that contain dependencies that might update my entire system to, say, testing. Given that, are these lines still insane? Is there some way to tell apt to ask me if I want to install something from a particular repository, for example, something I want to test. I would like to have apt tell me "that's not in one of these repositories but it's in one of these other repositories you have in sources.list, ok to install it from there?" Something like a warn-me flag? Or something that shows me what repository I'm about to install something from? I was sort of hoping that's what setting a priority <500 would do. Here's an updated version now of what I have, though I would uncomment testing and experimental if I understand correctly. Wondering if I should also add unstable in there at an equally low priority. /etc/apt/sources.list deb http://security.debian.org/debian-security/ bullseye-security main contrib non-free deb-src http://security.debian.org/debian-security/ bullseye-security main contrib non-free deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free deb-src http://deb.debian.org/debian/ bullseye-backports main contrib non-free deb http://deb.debian.org/debian/ bullseye main contrib non-free deb-src http://deb.debian.org/debian/ bullseye main contrib non-free #deb http://deb.debian.org/debian/ testing main contrib non-free #deb-src http://deb.debian.org/debian/ testing main contrib non-free #deb http://deb.debian.org/debian/ experimental main contrib non-free #deb-src http://deb.debian.org/debian/ experimental main contrib non-free /etc/apt/preferences Package: * Pin: release a=bullseye-security Pin-Priority: 1000 Package: * Pin: release a=bullseye-updates Pin-Priority: 950 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 signature.asc Description: PGP signature
Re: Moving from Testing to Stable + Backports
On Mon, Aug 16, 2021 at 05:10:36AM -0400, Michael Grant wrote: > I've been using Testing for about a decade now with very few problems. > But now I'm moving to Stable. > sources.list > deb http://security.debian.org/debian-security/ bullseye-security main > contrib non-free > deb-src http://security.debian.org/debian-security/ bullseye-security main > contrib non-free > > deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free > deb-src http://deb.debian.org/debian/ bullseye-backports main contrib non-free > > deb http://deb.debian.org/debian/ bullseye main contrib non-free > deb-src http://deb.debian.org/debian/ bullseye main contrib non-free You're missing the "bullseye-updates" repository, but it's optional. If the lines above were the only lines in your sources.list, you would be doing it correctly. Bullseye-backports is also optional, and there probably aren't any yet. And even when there are some, there's no guarantee that you'll need them. Personally, I prefer to leave the -backports out of it unless and until I actually need one. But if you want to bring it in proactively, that's acceptable. > deb http://deb.debian.org/debian/ testing main contrib non-free > deb-src http://deb.debian.org/debian/ testing main contrib non-free *THIS*, however, is wrong. With testing lines added to your sources.list, you are not running stable (bullseye) any longer. You are still running testing, just with a fallback option to retrieve bullseye packages as well. > deb http://deb.debian.org/debian/ experimental main contrib non-free > deb-src http://deb.debian.org/debian/ experimental main contrib non-free And this is just stupid. Remove this immediately.
Re: Moving from Testing to Stable + Backports
On Mon, Aug 16, 2021 at 05:10:36AM -0400, 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. > > My intention is that when I upgrade or install something from now on, > I want to take the latest most resonable version of it. > > If there's a security update, I want that version first. > > 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. > > 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? > > Lastly, I want to be able to manually install things from testing and > from experimental. > > Here's my apt config files: > > sources.list > deb http://security.debian.org/debian-security/ bullseye-security main > contrib non-free > deb-src http://security.debian.org/debian-security/ bullseye-security main > contrib non-free > > deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free > deb-src http://deb.debian.org/debian/ bullseye-backports main contrib non-free > > deb http://deb.debian.org/debian/ bullseye main contrib non-free > deb-src http://deb.debian.org/debian/ bullseye main contrib non-free > > deb http://deb.debian.org/debian/ testing main contrib non-free > deb-src http://deb.debian.org/debian/ testing main contrib non-free > > deb http://deb.debian.org/debian/ experimental main contrib non-free > deb-src http://deb.debian.org/debian/ experimental main contrib non-free > > 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 > I don't know about the pinning priorities ... [Taken from https://wiki.debian.org/SourcesList] deb http://deb.debian.org/debian bullseye main contrib non-free deb-src http://deb.debian.org/debian bullseye main contrib non-free deb http://deb.debian.org/debian-security/ bullseye-security main contrib non-free deb-src http://deb.debian.org/debian-security/ bullseye-security main contrib non-free deb http://deb.debian.org/debian bullseye-updates main contrib non-free deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free are the primarly /etc/apt/sources.list entries. Security updates will normally be applied to stable anyway but if you've got bullseye-security in there, they get pulled in. I also have unattended-updates or whatever it's called enabled. deb http://deb.debian.org/debian bullseye-backports main contrib non-free deb-src http://deb.debian.org/debian bullseye-backports main contrib non-free are the corresponging backports lines - I suspect there's nothing there at the moment but you normally have to explicitly pull backports by name - they're not installed by default, even if you have them enabled. Hope this helps, all the best, as ever, Andy Cater
