On 01/23/2018 02:54 AM, Simon McVittie wrote:
I'm finding it hard to reconcile the factors involved here: * sufficiently change-averse to be unwilling to upgrade to Debian 9 after the non-LTS support lifetime of Debian 8 has expired, approximately 1 year after the release of Debian 9 (or since you were initially talking about wheezy-backports, the same thing for Debian 8 and Debian 7); * but sufficiently tolerant of regressions to be willing to upgrade individual packages to versions that have not had anywere near the same amount of testing as an integrated system as what's in any single stable release I'd consider stable + backports to be a middle ground between stable and testing, for people who are willing to tolerate some regression risk in exchange for newer packages, but not as much regression risk as if they were running testing or unstable. It's harder to see what the niche in the ecosystem is for oldstable-LTS + backports - if you want newer software than oldstable, stable is right there, with direct security support from package maintainers and the security team.
I can't seem to find it now, but I believe somewhere official there is (or was at one time?) a diagram showing how LTS would allow skipping stable versions: for example, going directly from Wheezy to Stretch, and stretch to Bullseye, skipping Jessie and Buster.
That indicates (provided I'm not making it up!) that the goal of LTS isn't a middle ground between stable and testing, but rather to reduce the requirement to completely upgrade systems by 50%.
Backports can be really handy for achieving this goal: when you're running oldoldstable quite successfully, but you need a couple of newer packages. Isn't that the niche that backports is intended to fill?
I still believe it's particularly useful for the kernel: with a backported Jessie kernel, new hardware like NVMe drives magically works on Wheezy.
LTS and backports seem like ideal partners, but it turns out (by surprise, but that's a different issue) that they're not.
I wouldn't be surprised if the kernel packages are by far the most popular backport, even on a lot of systems the only backport.The kernel is relatively self-contained, so if the kernel and maybe some firmware are a special case, perhaps installing the stable kernel on an otherwise oldstable system would be a viable option that would not require someone to maintain a separate kernel backport?
That's certainly an option. Doesn't that argue against the need for a kernel backport at all? Surely there are advantages to having a true backport, like guaranteeing that device enumeration and naming stay the same, the kernel would be compiled by the same compiler as the rest of the system, any custom/non-standard kernel modules would have to be re-thought, there are probably a dozen other reasons I don't even know about.
But maybe you've got actual data that the kernel isn't a popular backport, and maybe I'm completely wrong about the goals of LTS. That's certainly possible.