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:
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.
I did this because I thought it would be worthwhile seeing if Debian
thought there was anything here to be learned, about how to better
support some of its users. If those responsible for these services
don't think so, then, well, as users we get what we pay for.
If those responsible for -backports don't value this kind of feedback
then of course next time I can not write it up as a learning
opportunity for Debian. I can just work around it instead.
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.
>
> I very much disagree with that. That situation obsoleted the one in
> -backports, and thus it made no sense to continue to carry it.
>
> > 2. Cruft removal in stable releases, including in -backports, should
> > perhaps be done with care/caution/announcement or something.
>
> -backports accompanies stable. There was no package removed from the
> complete suite of stable + -backports. Also, we also remove packages
> >from -backports when they become unavailable in testing/unstable and
> thus can't be considered a backport anymore. That includes packages
> that weren't even in stable - which isn't an easy decision, but it
> doesn't make sense to carry packages solely in -backports (which isn't
> the case here - just as a help for understanding the background).
[and later:]
> > Q. Why was linux-base removed from jessie-backports ?
...
> I very likely would still
> do it because having unsupported packages lying around makes very little
> sense because it sends the wrong message.
I get the impression that your mind is made up that I was doing
something wrong. That's fair enough (even though I don't understand
what it is I am supposed to have done wrong except maybe not having
managed to get this thing onto stable yet - after all, it's not your
responsibility to explain that to me).
I will say one thing though: your response seems primarily to be based
on general rules which I guess are agreed amongst the backports team.
I had hoped that it might be possible to examine whether those rules
are always right, or should perhaps be changed.
(Also I am in general extremely sceptical about arguments along the
lines of `this is to send the right message'.)
You also gave some suggestions for how I should proceed on a technical
level. Thanks for trying to help. Of course how I proceed is up to
me and I don't need to convince you. And as I say I have worked
around the problem now.
But for the benefit of others reading, at least, it seems like I
should at least mention a couple of things where I don't agree with
what you have said.
> > Using the jessie-backports kernel with the jessie installer involves
> > using the preseed hook mechanism to add jessie-backports to the
> > target's apt sources, and an in-target apt-get install rune to install
> > the kernel package.
> >
> > (Using the jessie-backports kernel also involves editing the installer
> > image to have the jessie-backports kernel and modules, but that is not
> > relevant to this tale.)
>
> I don't really follow - you now can get rid of that special casing
> (which had to be added specifically) and reduce complexity. I actually
> see this even as a win situation for your setup.
In fact, that's not right. It definitely adds an additional special
case.
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.
But you are telling me that whether I need the first rune depends not
only on whether I need a newer kernel. It also depends on whether a
newer linux-base exists in foo-security: if it does, I *must* omit the
first rune; if it does not, I *must* include it.
So whether my automation needs this rune varies, (i) according to the
value of `foo', and (ii) with time. Of course it is not OK for my
system to randomly rot in an uncontrolled way, especially when the
root cause is a security update (which might occur at any time).
I think that with the current backports policy this means I have to
use snapshot.d.o any time I want to use a backports kernel. In fact I
think anyone who is doing automatic installation needs to use
snapshot.d.o for backports.
You are of course free to consider that "automatic installation using
backports kernels" is an unimportant niche use case.
> Please simply remove the special casing and move on? I really don't
> understand why this needs to be made a big fuzz about.
I need an approach that means that our CI will not suddenly break
because of some distant security update and consequent cruft removal.
This time it broke during the Xen freeze (which is unfortunate) and at
a time when I was away a fair amount (which is also unfortunate) but
at least not when I was away for several weeks (which is fortunate).
Next time we might be less lucky. I doubt my Xen Project colleagues
would have been able to fix this. I guess if I could not be reached,
we would have dropped testing for one of our release architectures.
> Thanks for bringing this to our attention. I think what we can do is
> announce removal of packages to make people aware of the whys.
Increased communication would certainly be welcome.
Thanks for your attention.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
