Bug#638024: user story --- bad Default-Release breaks unattended-upgrades
David Kalnischkies wrote:
> On Wed, Jan 24, 2018 at 02:10:43PM +1100, Trent W. Buck wrote:
> > As part of my Best Current Practice I set Default-Release "stretch",
> > to prevent accidental dist-upgrades when sources.list is in an unusual state.
> > (For THIS server, that's unlikely, but it's BCP so I do it everywhere.)
>
> As your entire story depends on this, could you tell us please what you
> mean here? "accidental dist-upgrade" and "unusual state" don't make
> a lot of sense to me.
Sorry that wasn't clear.
The unusual state I'm thinking of is along the lines of this:
* my normal system runs stable
* the frobozz maintainer claims #123456 is fixed in unstable, and asks me to check it
* rather than setting up a whole new unstable test VM,
just enable unstable in sources.list temporarily,
cherry-pick frobozz, test it, then downgrade again.
(Obviously this wouldn't work for something hairy like mysql, but
for GUI apps it's usually fine.)
* whoops, "apt install frobozz" has upgraded libc and friends because I wasn't paying attention and just hit yes.
Now important parts of my system are running unstable, not just that app.
When Default-Release is set, in that last step, I have to explicitly ask for any dependencies that can't be met from stable.
These days I personally am more likely to roll an in-house backport
package, but at least three times my coworkers (who aren't debian
experts) have bricked their laptops by trying something along these
lines, usually because "stackoverflow/reddit said this would work".
This is also a helpful safety net if I forget to remove unstable from sources.list afterwards.
In the old days, before I knew about rmadison, I would just leave my
system with stable, testing, unstable and experimental all enabled,
but only actually install stuff from stable, so I could use apt-cache
policy to find out what versions of frobozz debian had.
Now that you've made me spell it out, I realize that a lot of the
stuff I've described isn't officially supported, and I haven't
actually used much since about 2013.
I guess at this point I'm setting Default-Release out of habit, because
it's saved me from my own stupid mistakes in the past.
> Nuking /var/lib/apt/lists isn't the best practice either as some
> security features use the "old" data to put up constraints for the "new"
> data – including that a repository can't change its Codename from
> "buster" to "bullseye" without a user explicitly confirming this (even
> if "stable" is written in the sources.list – implemented in 1.5 which is
> why I talk about stable+1 and stable+2 at the time of writing).
When I have persistent storage, I keep /var/lib/apt/lists.
The case where this bit me was a Debian Live environment,
where to keep the image small (<128MB) I habitually strip out a lot of stuff,
including apt lists.
I didn't know about the safety net stuff you describe;
that might be valuable enough to compile apt lists into the Debian Live image —
I'll try it and see how it affects image size and boot time.
Let's see, normal build gives me
4.7M live/boot/vmlinuz
17M live/boot/initrd.img
85M live/boot/filesystem.squashfs
106M total
Including /var/lib/apt/lists gives me
4.7M live/boot/vmlinuz
17M live/boot/initrd.img
98M live/boot/filesystem.squashfs
119M total
So, a 10.9% increase in image size.
Bleh — although it's still <128MiB, so I'll think about it.
Reply to: