[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How automatic are backport package updates?



On Sat, Feb 13, 2021 at 02:32:56PM +0000, Andrew M.A. Cater wrote:
> The below is my opinion: it is informed by watching other folk have problems over the years.
> 
> TLDR; - If you are running a production system - run Debian's latest stable release. Stable 
> gets security support and backported fixes for security issues.
> 
> Release overview:
> ================
> 
> Debian releases trickle down over a period of years: Unstable (code name Sid) -> Testing -> Stable.
> [There is also an Experimental repository - but I'll leave that out for the sake of brevity].
> 
> Fictious example: Take the case of a brand new package Foo which, we'll say, is a personal productivity
>  app. and updates regularly but on a fairly long timescale.
> 
> Debian unstable == codename "Sid"
> ---------------------------------
> 
> If package foo is introduced today, it will go into Sid in source code form and be built there. Sid is never
> expected to be released in this form and receives no formal security or other support. If you run Sid, you're
> expected to be experienced enough to fix any problems yourself. Major upgrades of something like a desktop
> environmnent can sit in Sid for many months until all the components are ready and all dependencies are 
> sorted out. Package churn can be severe and unpredictable.
> 
> After a short while with no major problems, and a minimal amount of testing, package foo can pass to Testing. 
> 
> Debian testing == codename "Bullseye" == Debian 11 when released.
> ----------------------------------------------------------------
> 
> "Testing" is preparation for the next large scale release of Debian.Testing effectively collects packages for
> a couple of years until a freeze period and eventual release. [Debian 11 (code name Bullseye) - is at that
>  stage at the moment: the freeze period has started relatively recently - it may be released in June 2021 or 
> so following further freeze stages, all other things being equal.] 
> 
> At this point, package foo will not go into current stable: it will only be prepared for the NEXT release of
> Debian months or years away.
> 
> There is a backports repository. This is a way to run a small number of packages from Debian testing on a
> stable system. This might, for example, be an updated kernel because 5.10.x runs on your brand new hardware
> whereas 4.19.x won't run the hardware correctly. These packages are built against the versions of the packages
> in Debian stable (otherwise they won't run there) but provide new/different versions to those supported in stable.
> No security support as such - if you're running backports, you are very much on your own / out as an edge case
> 
> If enough users of Debian stable really wanted package foo, it could, conceivably be put here into the backports
> repository, but if it wasn't originally released as part of stable, you can't readily slipstream something straight
> into Stable..
> 
> Package version numbers:
> -----------------------
> 
> Very well established packages might have the same or subtly different versions from Sid all the way down to stable. 
> It could be that there's version 4.x newly released in Sid, 3.x in Testing and 2.x in Stable for example with the 
> different versions reflecting different codebases. 
> 
> Stable release == Debian 10 (Buster) as at 20200213
> ==============
> 
> As of today: Debian's latest stable release is Debian 10 - codename Buster - and the point release is Debian 10.8 (released on
> February 8th, 2021). In due course, there will likely be a 10.9 - updates which roll up security updates / changes etc. occur
> approximately every three months.
> 
> If you run a stable system, and keep it regularly updated, then the point releases will be very small changes as they occur.
> 
> "Frankendebian"
> ---------------
> 
> You shouldn't cherry pick between releases because that leads to instability. Likewise "I'll just pull XYZ from Ubuntu and
> expect it to work on Debian X" will occasionallly work but more often than not produce impossible problems fo dependency 
> and version instability which require significant unpicking.
> 
> All best, as ever,
> 
> Andy C.

Thanks Andy, Tixy, Andrei, Dan and others who have chimed in on this.

You all have convinced me to move to stable+backports.

One comment though, in the 10+ years of running Debian Testing, I have
to say that Testing is actually very reliable, way more reliable than
it's name implies!

I initially moved to Testing because there were some packages that I
needed which were not in Backports and were regularlly maintained in
Testing.  I'm afraid I don't recall which packages anymore, I think it
might have been Sendmail.  Back then I thought (perhaps mistakenly)
that Testing was getting security fixes.  

Let me add to your recommendations above:

For the packages in Testing which don't make it into Backports, one
can first try to try to install the package from Testing, but if it
attempts to bring in other dependencies from Testing, stop.  If you
can't wait for the next release of Debian or someone to do a backport,
then the next best option is to try and build a backport yourself.
Pull down the source from Testing and use dbuild and build a local
package on Stable and apt install it.  This often works unless the
package depends on kernel or other specific things in the next Debian
release.

That process is detailed here:

https://wiki.debian.org/SimpleBackportCreation

Building packages has definitely gotten easier.

I completely understand the desire for stability and reliability.  But
it seems like having to wait up to 2 years for some major new feature
to get into Debian can be daunting, especially when it gets into
Testing.  I was wondering, is there, or has anyone given any thought
to something in between Testing+Backports and Stable+Security that is
something like Stable at each dot release, thus reducing this window
down to 3 months as opposed to 2 years?

Michael Grant

Attachment: signature.asc
Description: PGP signature


Reply to: