The only outcomes that could occur are
apt ------ snap
error ---- not installed (1)
success -- installed (2)
error ---- installed (3)
Of course there is a period where the snap installation could be
in progress, but it should be a transitional state.
> leaves the device with a partially installed snap.
If the installation fails with the error reported in this bug ("snap
installation in progress" — exit status 10), then indeed the deb can be left in
some non-installed state[1]. The snap, however, will never be partially
installed. It will be either installed or in the process of being installed.
All that would be a correct outcome in my opinion, although I do not argue that
it is confusing that Apt says "I give up, the package installation fail"
whereas Snapd is nonetheless chugging along, installing Chromium albeit slowly
(outcome 3 above). I searched and asked around but could find no evidence for a
time-out in Dpkg's maintainer scripts.
If you ever get that again and can gather evidence of a partially installed
snap, please do correct me. I fail to see such evidence in LP:1891373 either;
There, the *deb* is partially installed, but then the user forced the Apt
process to end, which is usually indeed a bad idea.
> To clarify when I say the package should handle its own failure
scenarios, I don't mean that it shouldn't fail, just that it should put
the system back into the state it was in before the failure rather than
leave something behind that could cause problems with future
installations.
I agree there. There is a denominator problem that Apt does not handle
interruption well.
> I appreciate that this may be a difficult one to get to the bottom of
> and appreciate your patience.
I likewise appreciate your constructive comments and please let me know if
anything was unclear or if you disagree or if you have a suggestion to
reproduce the issue etc..
[1] https://www.debian.org/doc/debian-policy/ch-
maintainerscripts.html#details-of-unpack-phase-of-installation-or-
upgrade
Am 06/11/2024 um 16:07 schrieb [email protected]:
> I've tested this again just now and in typically I cannot get it to fail
> again on my computer. I've asked someone else to test and although it
> took about 10 minutes compared to the 10 seconds it took me, it did
> complete. This is despite us being sat next to each other on the same
> network and their device being a higher specification than mine.
>
> After replicating this bug during the Ubuntu Summit, then me replicating
> the failure on a Canonical employees device in the same way, I'm certain
> in some scenarios it fails and leaves the device with a partially
> installed snap. Perhaps this is down to the snap taking a long time to
> download then hitting a timeout whilst the install is occurring? You can
> see a report of this in the linked bug #1891373.
>
> To clarify when I say the package should handle its own failure
> scenarios, I don't mean that it shouldn't fail, just that it should put
> the system back into the state it was in before the failure rather than
> leave something behind that could cause problems with future
> installations. I appreciate that it may be difficult to do this if
>
> I appreciate that this may be a difficult one to get to the bottom of
> and appreciate your patience.
>
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1886414
Title:
the chromium snap takes a long time to install without visible user
feedback, seems stuck
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1886414/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
