Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On Du, 11 iul 21, 06:54:31, The Wanderer wrote: > On 2021-07-11 at 03:31, Andrei POPESCU wrote: > > > > While your testing + stable as needed mix is pretty simple[1] the > > reverse mix stable + select packages from testing requires adequate > > pinning and can quickly become problematic for anything but the > > simplest packages packages (no or very few dependencies) pulled from > > testing. > > I can see how it could become an issue for someone who's trying to stick > mainly with stable, but that's never been my goal. As soon as you > dist-upgrade against the combination of testing and stable, you're > primarily on testing, with stable present only as an "in case of > removal" backstop. Unless one has appropriate pinning in place ;) > > You should be using -backports instead or backport packages yourself > > if necessary[2]. > > I hope this is general/generic "you", and not directed at me > specifically. I first read this as chiding me against running this mix, > and that came across as mildly offensive. Indeed it was, apologies for the bad wording. In my head it didn't apply to you because you aren't actually running that mix. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On 2021-07-11 at 03:31, Andrei POPESCU wrote: > On Sb, 10 iul 21, 14:38:39, The Wanderer wrote: > >> On 2021-07-10 at 14:18, Andrei POPESCU wrote: >>> It depends :) >>> >>> In my opinion I'd say the order from less to more dangerous >>> would be: >>> >>> 1. stable + select packages from stable-backports >> >>> 2. oldstable + select packages from oldstable-backports-sloppy >> >>> 3. testing + select packages from unstable >> >>> 4. unstable + select packages from experimental >> >> I'm a little surprised to see that you don't even mention the mix >> which I've been running for the last decade-plus: stable + testing, >> which works out to testing + select packages from stable (the ones >> which are no longer available in testing). >> >> Do you consider that to be so dangerous as to not even be worth >> mentioning? > > What I forgot to mention was that outside the common scenarios above > you are pretty much on your own and you should have a good > understanding of APT priorities and pinning (or be prepared to deal > with problems). > > The danger level also varies greatly on which is your "main" > release. > > While your testing + stable as needed mix is pretty simple[1] the > reverse mix stable + select packages from testing requires adequate > pinning and can quickly become problematic for anything but the > simplest packages packages (no or very few dependencies) pulled from > testing. I can see how it could become an issue for someone who's trying to stick mainly with stable, but that's never been my goal. As soon as you dist-upgrade against the combination of testing and stable, you're primarily on testing, with stable present only as an "in case of removal" backstop. > You should be using -backports instead or backport packages yourself > if necessary[2]. I hope this is general/generic "you", and not directed at me specifically. I first read this as chiding me against running this mix, and that came across as mildly offensive. > [1] No pinning required, unless you want to have *very* good control > over what you install from stable. A similar reasonably safe and > easy setup is unstable + testing as needed, which is probably a good > idea anyway, even if not well documented. I used to track testing + unstable, which worked out to unstable + select packages from testing. That's the setup which blew up under my feet into an inconsistent, unrepairable Debian installation, as I've mentioned elsewhere in this thread. However, I do not blame that on the fact of running a combination of suites. I blame it on the fact of tracking unstable at all. I absolutely do not recommend tracking sid on a production system, ever. Installing specific packages from sid, carefully and only as needed, is one thing; dist-upgrade against sid is something I very strongly recommend against. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On Sb, 10 iul 21, 14:38:39, The Wanderer wrote: > On 2021-07-10 at 14:18, Andrei POPESCU wrote: > > > On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote: > > > >> On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote: > >> > >>> Hi, Debian unstable with bits of experimental here > >> > >> Is it (usually) wise to intermix different suites? > > > > It depends :) > > > > In my opinion I'd say the order from less to more dangerous would > > be: > > > > 1. stable + select packages from stable-backports > > > 2. oldstable + select packages from oldstable-backports-sloppy > > > 3. testing + select packages from unstable > > > 4. unstable + select packages from experimental > > I'm a little surprised to see that you don't even mention the mix which > I've been running for the last decade-plus: stable + testing, which > works out to testing + select packages from stable (the ones which are > no longer available in testing). > > Do you consider that to be so dangerous as to not even be worth mentioning? What I forgot to mention was that outside the common scenarios above you are pretty much on your own and you should have a good understanding of APT priorities and pinning (or be prepared to deal with problems). The danger level also varies greatly on which is your "main" release. While your testing + stable as needed mix is pretty simple[1] the reverse mix stable + select packages from testing requires adequate pinning and can quickly become problematic for anything but the simplest packages packages (no or very few dependencies) pulled from testing. You should be using -backports instead or backport packages yourself if necessary[2]. [1] No pinning required, unless you want to have *very* good control over what you install from stable. A similar reasonably safe and easy setup is unstable + testing as needed, which is probably a good idea anyway, even if not well documented. [2] If you do that you might as well consider providing them via -backports, with the help of a sponsor. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On Sat 10 Jul 2021 at 13:48:12 -0500, Brian Thompson wrote: > On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote: > > Testing doesn't have any direct security support > > Is that 100% true? I was originally referring to Almost, for most of the time and in normal circumstances.. It depends on how serious the securuty breach is. -- Brian.
Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On Sat, Jul 10, 2021 at 01:48:12PM -0500, Brian Thompson wrote: > Thank you for the detailed response, Andrei. > > On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote: > > Testing doesn't have any direct security support > > Is that 100% true? I was originally referring to > http://security.debian.org/debian-security/dists/testing-security > when I was talking about "testing security updates". I understand that most > mirrors don't contain this suite, but it seems to be working pretty well along > with the "main" mirror I am using for testing updates (i.e. one that is closer > in proximity). Several years ago, a decision was made to offer a repository for security updates in testing. Perhaps some packages even appeared there, though I cannot confirm that. There have not been any packages there for a *really* long time. It's just empty.
Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
Thank you for the detailed response, Andrei. On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote: > Testing doesn't have any direct security support Is that 100% true? I was originally referring to http://security.debian.org/debian-security/dists/testing-security when I was talking about "testing security updates". I understand that most mirrors don't contain this suite, but it seems to be working pretty well along with the "main" mirror I am using for testing updates (i.e. one that is closer in proximity). Perhaps mixing mirrors is a bad practice, but I haven't run into any issues for the past week since I started using this apt configuration. > > > I wanted to do the same thing with getting testing security updates into > > unstable, but I didn't think that was wise (plus it's the other way > > direction). > > It's unclear to me what exactly you meant with this, but I think I > addressed it above anyway. Yes, you did. Plus it wouldn't make sense to pull the testing-security suite I mentioned above into unstable, would it? -- Best regards, Brian signature.asc Description: This is a digitally signed message part
Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On Sat 10 Jul 2021 at 14:38:39 -0400, The Wanderer wrote: > I'm a little surprised to see that you don't even mention the mix which > I've been running for the last decade-plus: stable + testing, which Most likely an oversight. -- Brian.
Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On 2021-07-10 at 14:18, Andrei POPESCU wrote: > On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote: > >> On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote: >> >>> Hi, Debian unstable with bits of experimental here >> >> Is it (usually) wise to intermix different suites? > > It depends :) > > In my opinion I'd say the order from less to more dangerous would > be: > > 1. stable + select packages from stable-backports > 2. oldstable + select packages from oldstable-backports-sloppy > 3. testing + select packages from unstable > 4. unstable + select packages from experimental I'm a little surprised to see that you don't even mention the mix which I've been running for the last decade-plus: stable + testing, which works out to testing + select packages from stable (the ones which are no longer available in testing). Do you consider that to be so dangerous as to not even be worth mentioning? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]
On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote: > On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote: > > Hi, Debian unstable with bits of experimental here > > Is it (usually) wise to intermix different suites? It depends :) In my opinion I'd say the order from less to more dangerous would be: 1. stable + select packages from stable-backports Generally quite safe, though security support for -backports is on best-effort basis and could be delayed for various reasons. 2. oldstable + select packages from oldstable-backports-sloppy Package versions in -backports-sloppy are also from testing, so an upgrade from oldstable to stable is much more likely to run into issues if you start with this mix. Besides, oldstable only receives security support for one year after the last stable release, to allow sufficient time to prepare the dist-upgrade. This mix makes sense e.g. if you intend to keep running a system on oldstable for a very limited time (a few moths or so), that will then be decommissioned, reinstalled etc. instead of dist-upgraded to stable. 3. testing + select packages from unstable Testing doesn't have any direct security support, but security fixes should be migrated faster from unstable. Whenever this is not the case (why?), it could make sense to upgrade specific packages. Similar considerations for bug fixes, in expectation that the package will eventually migrate to testing. Be prepared to handle the situation where the package will not migrate as expected (or ever). 4. unstable + select packages from experimental Experimental is an incomplete suite (same as -backports), it can only be used on top of something, typically unstable. Packages in experimental can be everything from (surprise!) experiments that will never make it to unstable, test packages long forgotten that might not even install properly on any recent Debian, pre-releases of newer upstream versions (yummy!), to release-quality packages that are uploaded there instead of unstable during the freeze (as per Release Team's policy). The -backports (-sloppy probably as well) and experimental archives are treated specially by APT, no additional configuration should be necessary for the typical use case mentioned above. For combination 3. you probably want to use a setup similar with -backports for security upgrades and something similar to experimental for bug fixes. Understanding of APT pinning is a good prerequisite for such a setup, which is why I'm intentionally vague. ;) Of course, one way to learn is by actually trying it and breaking stuff (as most of us probably did). At a minimum you should avoid doing this in "production" (whatever that means for you). > I guess it wouldn't matter > that much for bits and pieces of experimental in unstable since you are > already > in agreeance with having an unstable system to begin with. Experimental can be way more dangerous than unstable, see above. Most (but not all!) packages in unstable are meant to eventually migrate to testing and then become part of the next stable release. > I wanted to do the same thing with getting testing security updates into > unstable, but I didn't think that was wise (plus it's the other way > direction). It's unclear to me what exactly you meant with this, but I think I addressed it above anyway. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
