On Sun, 27 Dec 2020 at 06:01:45 +0000, M. Zhou wrote:
> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.
You're using a suite named "unstable". It does what the name suggests. I
use unstable myself, but I wouldn't recommend it to anyone not prepared
to use an interactive apt resolver like aptitude and check that it's
doing something reasonable before letting it go ahead.
Automatic upgrades make a lot more sense for testing than for unstable,
and if we want security updates to be installed automatically for
non-technical users of stable (which I think we do), we do need to
be able to test the code responsible for that before we let it into a
stable release.
However, because the packages in testing are literally the same as the
packages in unstable, I'm not sure how we would configure one and not
the other to be upgraded automatically - particularly if the upgrade is
done by something distribution-neutral (like GNOME Software or KDE's
equivalent, as opposed to apt and unattended-upgrades) which doesn't
know the finer points of how Debian suites relate to each other.
Ubuntu might have some good ideas here: if I understand correctly,
their inconsistent unstable-equivalent is not generally used (except by
buildds), while their internally-consistent testing-equivalent is updated
from their unstable-equivalent with a 0-day migration delay and *is*
used by early adopters.
In the world of non-Debian distributions that *only* produce a rolling
release, my understanding is that Arch Linux is a bit like Ubuntu in this
respect - new packages go into a suite that is not recommended for use,
get a bit of QA/testing by their developers, and *then* go into the
rolling release that users are advised to actually install.
smcv
