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

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: