Bug#902653: unattended-upgrades: Please do not auto enable upon install
Hello, my opinion: If I install something by hand I do so because I want it's functionality. From this POV, it should be enabled. After all, if I install a package which does some "magic" I don't install and forget but take my time to review it's config files to understand how it works. If I don't want it's functionality (yet), I simply could remove or don't install in the first place. If it's installed by default on new installs, it maybe should be disabled to not do something unexpected. Since I don't do new installs but just clone a master install, my opinion isn't too relevant, maybe. It could be a simple solution to just print a message text about the status (enabled/disabled, reflecting probably existing conffile content) in postinst. I've seen other packages doing so do direct the user that he has to take further measures. Sites with many servers and some kind of automation (ansible or something similar) IMO should test new packages in a sandbox system before rollout to many machines automatically and having interesting surprises afterwards. At least, I'd consider this real-world practice. :wq! PoC PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc
Bug#902653: unattended-upgrades: Please do not auto enable upon install
Hi Olivier, Olivier Berger ezt írta (időpont: 2018. szept. 10., H, 9:02): > > On Fri, Jun 29, 2018 at 09:41:25AM +0200, Alexandre Detiste wrote: > > > > > some packages have unattended-upgrades as a dependency or in recommends > > > > I only see "plinth - web front end for administering every aspect of a > > FreedomBox" > > and "python3-software-properties" > > > > I have the feeling that python3-software-properties is in turn almost > always installed with Gnome nowadays (testing here)... which would make > unattended-upgrades run on every Gnome desktop basically. > > I'm noty sure this is the intended behaviour, even if the problem > probably lies in the python3-software-properties maintainer, then, and > where recommends is a too strong dependency ? Recommends is already a demotion from Depends, done in software-properties (0.96.19), but it is up to the maintainer to demote it further. I would still recommend installing u-u on desktops, too, and I made several changes recently to make u-u a good fit there, too, like skipping upgrades on battery and on metered Internet connections. Cheers, Balint > > Hope this helps. > > Best regards, > -- > Olivier BERGER > http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 > Ingenieur Recherche - Dept INF > Institut Mines-Telecom, Telecom SudParis, Evry (France) >
Bug#902653: unattended-upgrades: Please do not auto enable upon install
On Fri, Jun 29, 2018 at 09:41:25AM +0200, Alexandre Detiste wrote: > > > some packages have unattended-upgrades as a dependency or in recommends > > I only see "plinth - web front end for administering every aspect of a > FreedomBox" > and "python3-software-properties" > I have the feeling that python3-software-properties is in turn almost always installed with Gnome nowadays (testing here)... which would make unattended-upgrades run on every Gnome desktop basically. I'm noty sure this is the intended behaviour, even if the problem probably lies in the python3-software-properties maintainer, then, and where recommends is a too strong dependency ? Hope this helps. Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#902653: unattended-upgrades: Please do not auto enable upon install
Control: tags -1 wontfix Hi Annadane, 2018-06-29 9:26 GMT+02:00 annadane : > Package: unattended-upgrades > Severity: wishlist > > Dear Maintainer, > > If it were possible, I'd like to see unattended-upgrades not enable itself by > default when the user first installs it. I'm actually not sure what the > default is when you specifically tell it to install - aka "apt install > unattended-upgrades", but in any event I feel it should a) be off by default > unless the user specifically configures it to be on and more importantly b) > some packages have unattended-upgrades as a dependency or in recommends (I've > noticed it gets installed sometimes as an effect of installing some other > packages) - in that case ESPECIALLY it should really *not* be enabled by > default. Just my 2 cents. This also happens in Sid (it's not as catastrophic > in Stable though it can be) where one really wants to vet one's updates as > there's higher chance of breakage. Installing or not installing u-u by default is not up to the u-u maintainers, but up to the ones working on installers. It u-u's case I agree with their decision to have u-u installed by default since this package ensures that systems are kept up-to-date on server installs. U-u can be disabled by the administrator at any time, or it can be configured to keep a specific set of packages unaffected. A discussion about having it enabled can be read in #597061. If you are on stable or testing and any upgrade breaks, please report it, those breakages should be fixed. If you are on sid, since transitions can be in flight or due to other transient bugs your upgrades may fail, but unattended-upgrades is upgrading packages in minimal sets and as a Sid User you should be able able to recover from those states. Sid Users should be aware of the risks of running bleeding edge Debian and I updated the recommendations for them to consider disabling unattended-upgrades at https://wiki.debian.org/DebianUnstable Cheers, Balint
Bug#902653: unattended-upgrades: Please do not auto enable upon install
Hi, That's a recurrent anti-pattern that Debian tries to get away from, like the old /etc/default/$ ENABLED=yes stuff. Normal people expect stuff to just works out of the box; and things should be optimised for the most common case. You could rather use systemd functionnallity to disable/mask apt-daily-upgrade.timer. > some packages have unattended-upgrades as a dependency or in recommends I only see "plinth - web front end for administering every aspect of a FreedomBox" and "python3-software-properties" Greetings, 2018-06-29 9:26 GMT+02:00 annadane : > Package: unattended-upgrades > Severity: wishlist > > Dear Maintainer, > > If it were possible, I'd like to see unattended-upgrades not enable itself by > default when the user first installs it. I'm actually not sure what the > default is when you specifically tell it to install - aka "apt install > unattended-upgrades", but in any event I feel it should a) be off by default > unless the user specifically configures it to be on and more importantly b) > some packages have unattended-upgrades as a dependency or in recommends (I've > noticed it gets installed sometimes as an effect of installing some other > packages) - in that case ESPECIALLY it should really *not* be enabled by > default. Just my 2 cents. This also happens in Sid (it's not as catastrophic > in Stable though it can be) where one really wants to vet one's updates as > there's higher chance of breakage. > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), > LANGUAGE=en_CA:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled >
Bug#902653: unattended-upgrades: Please do not auto enable upon install
Package: unattended-upgrades Severity: wishlist Dear Maintainer, If it were possible, I'd like to see unattended-upgrades not enable itself by default when the user first installs it. I'm actually not sure what the default is when you specifically tell it to install - aka "apt install unattended-upgrades", but in any event I feel it should a) be off by default unless the user specifically configures it to be on and more importantly b) some packages have unattended-upgrades as a dependency or in recommends (I've noticed it gets installed sometimes as an effect of installing some other packages) - in that case ESPECIALLY it should really *not* be enabled by default. Just my 2 cents. This also happens in Sid (it's not as catastrophic in Stable though it can be) where one really wants to vet one's updates as there's higher chance of breakage. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
