Open Zirak opened 9 years ago
Imho, this should be left to the implementation. What happens if you run /pkg/installed/foo/uninstall
, and you run ls /pkg/installed
right after? Should the package be shown while the uninstall is run? Is it random?
This opens a lot more problems than it solves imho, so let's leave it implementation-defined.
By the way, this is surely the reason why apt and yum only allow one apt command to be run at a time.
Since we defer to the package manager, it'll be the same as if the user ran upgrade
, opened another terminal and ran list-installed
. It's perfectly valid.
If you use the package manager, it won't let you do that. With apt, you'll get this error:
E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?
huh? I just tested this on a ubuntu VM:
apt-get upgrade
dpkg -l
All was well with the world.
Ah, I see what you mean.
Let me think about it.
(I can't believe that's a word)
Let's say the user runs
/pkg/upgrade
and there're a lot of packages to upgrade. It's an IO-bound operation, completely out of our control, and it takes a lot of time.Smack in the middle of the upgrade, the user fancies a thing or another, and
ls /pkg/installed
. In the naïve, single-threaded and non-concurrent implementation (cough cough), this action will be blocked by the upgrade: Until the upgrade is complete, the user won't get hisls
back.That makes pandas sad.
Should non-blocking behaviour be part of the spec, or is it an implementation bonus? On some platforms (like Python) with an...erm... interesting concurrency model, this is very problematic, and could hamper implementation writers. On the other hand, not implementing this hampers UX.