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

Re: merged /usr vs. symlink farms



On Sun, Aug 22, 2021 at 12:26:46PM +0200, David Kalnischkies wrote:
> 
> So, when did you last log into your build chroot to upgrade dpkg and
> apt first? And while at that, did you follow the release notes – from
> the future, as they have yet to be written for the release you are
> arguably upgrading to already?

Personally, I never upgrade build chroots between major versions.  I
just use a tool like sbuild-createchroot to create them from scratch.
That's mainly because I need to keep the Buster chroot around for
backports, so I'll just create a new Bullseye chroot when I need it.

And of course my unstable chroot is continuously being upgraded but
that avoids most of the concerns people have about the Debian N to N+1
stable upgrade path.

> But okay, lets assume you actually do: apt and dpkg tend not to be
> statically linked, so they end up having dependencies....

So on my "pet" production systems (on my "cattle" systems I just
recreate them from scratch, e.g. "gce-xfstests create-image"[1] which
uses deboostrap), what I do is update /etc/apt/sources.list, and then
do "apt update ; apt-get install dpkg ; apt-get install apt" before I
run "apt-get dist-upgrade".  This handles the dependencies for me, and
while a few packages will get upgraded using the old dpkg and apt, the
vast majority of the packages will get upgraded using the latest
stable version of dpkg and apt.  This seems like relatively cheap
insurance; it doesn't hurt, and it might help avoid some nasty corner
cases that got overlooked during testing.

[1] https://thunk.org/gce-xfstests

> Don't get me wrong, as an apt dev I would love if we could do that. It
> is kinda annoying to work around issues you have fixed years ago, but
> aren't available in (soon) oldstable.

Well, I'll observe that if we told people to upgrade dpkg and apt
first using "apt-get install ...", this automatically handles the
dependencies, and while it doesn't make *all* of the potential issues
go away, I would think it would reduce the potential corner cases and
hence make it easier to test to make sure the right thing happens on
an update from Debian vN to vN+1, would it not?


> P.S.: As someone will ask: Ubuntu splits the user base in two: Those who
> run their release upgrader which runs outside of the packaging system and
> largely can do whatever (including bring in a standalone apt/dpkg just
> dealing with an upgrade – they usually resign to much simpler things
> through) and those who don't like for example chroots and containers who
> effectively use whatever an upgrade path 'apt dist-upgrade' gives you.

... and in my opinion, that's a *fine* strategy.  Sure, it would be
nice if "apt dist-upgrade" always worked smoothly, and that's a great
aspirational goal, but if we can reduce risks to users ---
particularly non-technical/non-expert users --- by using a release
upgrader which upgrades apt and dpkg first, we should do that.  So
let's take a page from Ubuntu, by all means!

					- Ted


Reply to: