public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
	"Thomas Lamprecht" <t.lamprecht@proxmox.com>,
	"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC qemu-server] apt hook: warn against using 'upgrade' command
Date: Mon, 9 Sep 2024 09:52:54 +0200	[thread overview]
Message-ID: <d544faec-5319-4f00-baa8-01fbd7a197bd@proxmox.com> (raw)
In-Reply-To: <232400452.25716.1725868091670@webmail.proxmox.com>

Am 09.09.24 um 09:48 schrieb Fabian Grünbichler:
>> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 06.09.2024 18:58 CEST geschrieben:  
>> Am 06/09/2024 um 12:40 schrieb Fiona Ebner:
>>> Many people will use 'upgrade' instead of 'full-upgrade' or
>>> 'dist-upgrade' (e.g. [0][1]) despite the documentation explicitly
>>> mentioning 'dist-upgrade' [3]. Proxmox VE uses different packaging
>>> guarantees than Debian and using 'upgrade' can lead to a broken
>>> system [2].
> 
> just a slight nit here: you should only end up with a broken system if we miss properly tracking some inter-package relationship. it can happen happen (and probably does, from time to time), but in the vast majority of cases "apt[-get] upgrade" should at most leave you stuck with an outdated system (with APT telling you that there are still packages to be upgraded), not a broken one. we did get a lot better about accounting for these things over the past few years (but of course, we don't have anywhere close to the infrastructure that Debian has for automated tracking and testing).

Okay, will change the commit message in v2.

> 
>>> The match is kept simple, to not accidentally catch things like
>>>> -o 'foo=bar upgrade baz'
>>> and trip up advanced users.
>>>
>>> It does not catch invocations with '-y' either, making it less likely
>>> to break automated user scripts. Although they should not use
>>> 'upgrade' either, it still would be bad to break them. If the risk is
>>> still considered too high, this change should wait until a major or
>>> at least point release.
>>>
>>> To avoid false positives, it would be necessary to properly parse
>>> options, which is likely not worth the effort.
>>>
>>> A downside is that the hook is only invoked after the user confirms
>>> the upgrade, but there doesn't seem to be an early enough hook entry
>>> (DPkg::Pre-Invoke is also too late). Since this is just an additional
>>> safety warning to guide new users, it should still be good enough.
>>>
>>> [0]: https://forum.proxmox.com/threads/150217/post-680158
>>> [1]: https://forum.proxmox.com/threads/140580/post-630419
>>> [2]: https://www.reddit.com/r/Proxmox/comments/ujqig9/use_apt_distupgrade_or_the_gui_not_apt_upgrade/
>>> [3]: https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#system_software_updates
>>>
>>
>> yeah, it's something I considered here and then but never pulled through,
>> as it just somehow doesn't feel right...
>>
>> But it's definitively a real problem, and so I surely won't block this on
>> the basis of some gut feeling, I'd rather like to hear Fabian's opinion on
>> it.
> 
> given that I also use `apt upgrade` from time to time (habit from being an unstable user ;)), and that it might alienate power users coming from Debian, I'd prefer this to be a non-interactive warning with the text "disarmed" a bit?
> 
> something like
> 
> !! WARNING !!
> Since Proxmox VE follows a rolling release model, using 'upgrade' can lead to a system being stuck on outdated versions, or in rare cases, break upon upgrading. Use 'dist-upgrade' or 'full-upgrade' instead.
> !! WARNING !!
> 
> with or without a prompt (it's a pity that the hook is not executed with the config before the regular confirmation prompt, else we could just depend on that)?

Sounds good. And since it is so rare, I'd just leave out the additional
confirmation prompt then.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2024-09-09  7:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06 10:40 Fiona Ebner
2024-09-06 10:42 ` Fiona Ebner
2024-09-06 11:01 ` Dominik Csapak
2024-09-06 16:54   ` Thomas Lamprecht
2024-09-06 12:16 ` Alexander Zeidler
2024-09-06 16:56   ` Thomas Lamprecht
2024-09-06 16:58 ` Thomas Lamprecht
2024-09-09  7:48   ` Fabian Grünbichler
2024-09-09  7:52     ` Fiona Ebner [this message]
2024-09-09  7:57       ` Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d544faec-5319-4f00-baa8-01fbd7a197bd@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal