Hi, Here's a few extra of my cents (buy yourself some ice cream from it).
I'm not going to touch the subject of why packages should or should not be removed in particular cases, but I'd like to add some feedback from a point of view of another user who wants to end up with the same result, Jessie with 4.9 kernel. On 2/14/19 5:09 PM, Ian Jackson wrote: > Firstly, thanks for taking the time to read what I wrote. (Thanks > also for Sam for his helpful perspective.) > > Stepping back a bit, and firmly putting my `user' hat on For the user it is recommended to use meta packages to install kernels, so that they keep getting updated when ABI level is bumped, and to resolve dependencies. > My aim was to share my experience, because I guess the point of > jessie-backports (and of much of what we do in Debian) is to help > Debian's users. In this case I was a user who had something go wrong, > but I was in the unusually fortunate situation of being able (due to > my personal skills, my support network, and my available time) to > diagnose the problem and write up a report. As user, I also still have some jessie systems with 4.9 kernel. At first I did... apt-get install -t jessie-backports linux-image-amd64 ...which automatically drags in linux-base from backports. After reading these messages... https://lists.debian.org/debian-backports-announce/2018/07/msg00000.html https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html https://lists.debian.org/debian-lts-announce/2018/07/msg00021.html ...I switched to linux-image-4.9-amd64 in Jessie, and I haven't even been thinking about what happened to linux-base in that process until today. > Rhonda D'Vine writes ("Re: Removal of linux-base from jessie-backports broke > Xen upstream CI"): >> On 2/13/19 1:09 PM, Ian Jackson wrote: >>> 1. Packages should not be removed from foo-backports just because a >>> similar package is in foo-security, because there are situations where >>> a host may have been relying on the package being in foo-backports and >>> a similar (even, newer) package being in foo-security is not >>> sufficient. This kernel stuff is quite a snowflake, since kernel team wanted to keep updating the 4.9 kernel in Jessie, while that would be impossible after discontinuing jessie-backports. Renaming the meta-package and forcing all users to do $something to keep getting updates was bad, but at least within the limits and rules that Debian sets itself, something was made possible, by using a hack via -security to get updates to users. > I get the impression that your mind is made up that I was doing > something wrong. Stepping on thin ice here. :) .. Yeah, just install the meta-package, they're invented to handle dependencies for you! > When one is using a kernel from foo-backports, it is generally > necessary to have an updated linux-base. Previously I thought that > the way to ask for an updated linux-base is > apt-get -t foo-backports install linux-base > alongside > apt-get -t foo-backports install linux-image-riscv64 > or whatever. AIUI you have told me that is usually right. When using -t on the command line, it will also allow getting dependencies from that target release. There's no need to do anything with linux-base explicitly. > Increased communication would certainly be welcome. The communication in the linked messages above was very clear to me. It explained me why this choice had to be made, and what I had to change to keep getting updates. Being on debian-lts-announce is the least that can be expected from LTS users. Now, for your particular use case, the whole new package stuff doesn't seem to add value, because there's no arm64 support in the packages that are getting in via -security now. But, at least you would get inux-image-4.9.0-0.bpo.6-arm64 with 4.9.88 instead of ancient 4.9.18. \o/ Knorrie
