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.

Hi,

That's a recurrent anti-pattern that Debian tries to get away from,
like the old /etc/default/$<package> 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.

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 <fjfj109@protonmail.com>:

Hi Annadane,

2018-06-29 9:26 GMT+02:00 annadane <fjfj109@protonmail.com>:

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

Hi Maintainer,

I wanted to add that i was not expecting this to be enabled by default, and would also prefer if it was not.

This was causing issues within my lab when i was managing my machines with ansible, and runs against remote machines were failing due to lock files, caused by the system updating unknowingly to me. I had to investigate this issue, to see it was caused by the autoupdate.

As an average user, i was not expecting this.

Hopefully my input helps, Thanks!

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,

Hi Olivier,

Olivier Berger <olivier.berger@telecom-sudparis.eu> ezt írta (időpont:
2018. szept. 10., H, 9:02):

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

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