Re: Disabling automatic upgrades on Sid by default?
On Sun, 2020-12-27 at 15:33 +0200, Adrian Bunk wrote:
> On Sun, Dec 27, 2020 at 12:16:22PM +0000, Simon McVittie wrote:
> > ...
> > 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.
>
> I do see value in getting feedback from interactive users in unstable
> before migration to testing, this does prevent some regressions from
> entering testing. Personally I would even like to see the default 2
> day
> migrations we have now reverted to the original 10 day default.
>
> We've had surprisingly few of the "libc6 is broken and the system
> does
> not boot" or "postinst does 'rm -rf /${doesnotexist}'" kind of bugs
> in
> recent years, but users of unstable should know what they are doing
> and
> be prepared for any kind of breakage at any time when they use
> something
> that is aptly named "unstable".
>
> For many users a better solution might be to pin to testing with
> automated upgrades, and only manually "apt-get -t unstable"
> install/upgrade from unstable.
The problem with using testing as a rolling distro is that the package
migration process often causes big delays that can block upgrades that
include security fixes, making use of testing alone thus a big security
risk. It is unfortunate that although sometimes upgrades with security
fixes are rushed into testing quickly to avoid this, I've seen too many
examples before of this not happening for me to be comfortable using
testing. It is for this reason alone that I personally choose to use
unstable, and I'm sure that I'm far from alone.
Using testing and manually pulling in select upgrades from unstable in
such situations addresses that issue in theory, but places a huge
burden on users to determine each day what unstable updates might
include a security update. I'm not sure there's a reliable enough
automated means of accomplishing this. We also have to consider not
only doing this for our own personal machines but also others which we
may manage, like those of family members (should we choose to give them
debian and not want to leave them with the "outdated" packages of
stable).
Given than many like myself use unstable for our personal daily-use
systems as though it were a proper rolling debian distro, it is thus
very problematic for package maintainers to treat unstable as a testing
ground to the extent of expecting that we must be "prepared for any
kind of breakage". I can tolerate minor bugs, but cannot-boot type
issues would be a big problem for me. Thankfully I've rarely
encountered such a big problem in my use of unstable thus far.
What would be best for most people like myself using testing/unstable
as though it were a real rolling distro, who for one reason or another
cannot or do not wish to move to a real "rolling" distro like arch,
would be for debian to actually offer a real rolling channel alongside
the stable one. Surely this would not be burdensome.
As I envision it, we could have "rolling" and maybe "rolling-unstable"
(or "rolling-testing") with continual upgrades typically going directly
into "rolling", or with a 0-day migration from "rolling-unstable", with
the purpose of "rolling-unstable" being (1) for preparing multi-package
upgrades like with ppp and network-manager as which kicked off this
discussion, to avoid the upgrade conflict that caused, and (2) for
testing of anything with greater than normal potential to cause serious
will-not-boot type breakage (which might thus be given an unusual
larger migration delay, or a non-automatic migration). We thus get the
best of both worlds of current testing & unstable without the worst.
When it gets to "freeze time" for prepping a new stable release, a
snapshot of "rolling" could be taken as the new "stable-prep", and
worked on for a couple months or so with selective (direct or from-
rolling) upgrades until ready for release as stable. The big problem
would be how best to migrate those on current testing/unstable
channels.
Reply to: