Re: Debian stable + backports + testing

[Dan Ritter]

Yoann LE BARS wrote: 
> 
>   Usually, I am using Debian stable with backports, and I am quite happy
> with it. However, it turns out I will probably have to test some early
> versions of some software and libraries that are not in backports, such
> as Ardour and SDL2.
> 
>   Therefore, I am considering using a bit of testing into stable +
> backports. I am wondering if anyone can give me some advice in doing so.
> I guess I should set its priority like this:
> 
> Package: *
> Pin: release o=Debian, a=testing
> Pin-Priority: 50
> 
>   Can anyone give me some piece of advice with this?

You can do this. If I didn't care much about the long-term
usability of the machine, I would do this.

On the other hand, if I did care about the machine's usability
-- say, if it was my primary machine -- then I would use KVM to
set up a virtual machine that I could use to run stable +
testing. Any time I wanted to destroy and re-create it, I would.

-dsr-

Re: Debian stable + backports + testing

[Yoann LE BARS]

Hello everybody out there!

On 2021/08/29 at 01:25am, Dan Ritter wrote:
> You can do this. If I didn't care much about the long-term
> usability of the machine, I would do this.

In other word, this is really not recommended, am I right?

Well, the thing is I do care of long-term usability of the machine …

Best regards.

-- 
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Re: Debian stable + backports + testing

[Roberto C . Sánchez]

On Sun, Aug 29, 2021 at 02:05:44AM +0200, Yoann LE BARS wrote:
> 
> Hello everybody out there!
> 
> On 2021/08/29 at 01:25am, Dan Ritter wrote:
> > You can do this. If I didn't care much about the long-term
> > usability of the machine, I would do this.
> 
>   In other word, this is really not recommended, am I right?
> 
>   Well, the thing is I do care of long-term usability of the machine …
> 
>   Best regards.
> 
Definitely, mixing stable + (anothing other than official backports)
risks causing significant damage to the system:
https://wiki.debian.org/DontBreakDebian

That said, Dan's advice is quite solid: have your mixed environment in a
VM, chroot, or other virtual environment.  When it gets into an unusable
state (it very likely will at some point, especially as testing further
diverges from stable), you can wipe it clean and start over.

Just don't do it on your main workstation or server outside of some
virtual environment.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Debian stable + backports + testing

[Yoann LE BARS]

Hello everybody out there!

On 2021/08/29 at 02:26 am, Roberto C. Sánchez wrote:
> That said, Dan's advice is quite solid: have your mixed environment in a
> VM, chroot, or other virtual environment.  When it gets into an unusable
> state (it very likely will at some point, especially as testing further
> diverges from stable), you can wipe it clean and start over.

So, here is the way I get it: use Debian stable + backports as the
system basis. For cutting edge tests, use a virtual machine in which,
well, any adventurous experiment needed can be done, as it can be thrown
away any time.

Well, it seems quite reasonable. Thank you for the advice!

Best regards.

-- 
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Re: Debian stable + backports + testing

[Peter Ehlert]

On 8/28/21 5:35 PM, Yoann LE BARS wrote:

Hello everybody out there!

On 2021/08/29 at 02:26 am, Roberto C. Sánchez wrote:

That said, Dan's advice is quite solid: have your mixed environment in a
VM, chroot, or other virtual environment.  When it gets into an unusable
state (it very likely will at some point, especially as testing further
diverges from stable), you can wipe it clean and start over.

So, here is the way I get it: use Debian stable + backports as the
system basis.

Stability is really important for me.
I am more conservative and I Don't use Backports*. Stable Only.

my experimenting is done on other machines or separate systems (multi-boot)

*clipped from the Debian Wiki (https://wiki.debian.org/Backports)

"Backports are recompiled packages from testing 
 (mostly) and unstable 
 (in a few cases only, e.g. 
security updates), so they will run without new libraries (wherever it 
is possible) on a stable Debian distribution. It is recommended to pick 
out single backports which fit your needs, and not to use all backports 
available."

For cutting edge tests, use a virtual machine in which,
well, any adventurous experiment needed can be done, as it can be thrown
away any time.

Well, it seems quite reasonable. Thank you for the advice!

Best regards.

Re: Debian stable + backports + testing

[Andrew M.A. Cater]

On Sun, Aug 29, 2021 at 07:19:14AM -0700, Peter Ehlert wrote:
> 
> On 8/28/21 5:35 PM, Yoann LE BARS wrote:
> > Hello everybody out there!
> > 
> > On 2021/08/29 at 02:26 am, Roberto C. Sánchez wrote:
> > > That said, Dan's advice is quite solid: have your mixed environment in a
> > > VM, chroot, or other virtual environment.  When it gets into an unusable
> > > state (it very likely will at some point, especially as testing further
> > > diverges from stable), you can wipe it clean and start over.
> > So, here is the way I get it: use Debian stable + backports as the
> > system basis.
> Stability is really important for me.
> I am more conservative and I Don't use Backports*. Stable Only.
> 
> my experimenting is done on other machines or separate systems (multi-boot)
> 

Echoing this: if stability is important: use stable - currently Debian 11.
If everything works, fine.

Exceptionally: if your machine is too new for stable, then you might need
a backports kernel or similar.

If you want to do ANYTHING else: do it on a separate machine / in a VM.
That way - you have "vanilla" stable which is easily debugged.
You have stable+backports in a VM [unless you have the case where you
need backported kernel/firmware for basic booting] and you have anything 
else in a separate VM, maybe.

Don't make a FrankenDebian unless you absolutely must and you're sure
what you've done to get there and can undo changes.

All the very best, as ever,

Andy Cater