You are not logged in.
I would love to hear your thoughts on moving the "checking available disk space" functionality to a much earlier phase in the upgrade process for pacman. Ideally it could be done directly after identifying how many packages are to be upgraded i.e. as soon as we know how much disk space is actually required and prior downloading said packages.
There is no pressing need for this functionality, but it could help to avoid annoying half update procedures where someone many need to boot live and extend their root partition. It also just feels a little cleaner in terms of update/upgrade procedures.
Offline
Hard to say, my take on it is to check everything prior to an update and check space by myself. In case of lack start purging junk.
Something like BRTFS can cause headaches on the “available space” part...
Offline
I always considered that as a safety mechanism to prevent installation getting broken if space is exhausted during untaring. If pacman complains about insufficient space, I perceive it not as a graceful information to the user, but more like “OMG, I just prevented a disaster from happening and I’m bailing out!”
The information you ask for is also unavailable before the sync database is updated. The requested feature would require making incomplate updates a norm, which smells bad.
For those reasons I see that more like something that could be added to checkupdates (of community/pacman-contrib) — that’s the tool intended to be used for querying for updates without actually modifying anything.
(edit: I have just noticed expac has no option to pass the database path. So the idea below is more complicated than it sounds, as one needs to pass a custom “pacman.conf” with DBPath changed)
(edit: actually ignore that part. It would not take dependencies into account)
It doesn’t even has to be added to it: the functionality can be scripted by pointing expac (community/expac) with the %m format to checkupdates directory ("/tmp/checkup-db-$UID") and the main sync databse, and comparing the outputs.
Last edited by mpan (2021-01-26 06:40:19)
Paperclips in avatars? | Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
I would love to hear your thoughts on moving the "checking available disk space" functionality to a much earlier phase in the upgrade process for pacman. Ideally it could be done directly after identifying how many packages are to be upgraded i.e. as soon as we know how much disk space is actually required and prior downloading said packages.
pacman does not know WHERE it needs the space until the packages have actually been downloaded.
Offline
apg: if the files database is up to date, it knows that. See the -F option. E.g.:
$ pacman -Q 0ad
error: package '0ad' was not found
$ find /var/cache/pacman/pkg/ -name '0ad*'
$ pacman -Fl 0ad
0ad usr/
0ad usr/bin/
0ad usr/bin/0ad
0ad usr/bin/pyrogenesis
0ad usr/lib/
0ad usr/lib/0ad/
0ad usr/lib/0ad/libAtlasUI.so
0ad usr/lib/0ad/libCollada.so
0ad usr/lib/0ad/libmozjs38-ps-debug.so
0ad usr/lib/0ad/libmozjs38-ps-release.so
0ad usr/lib/0ad/libnvcore.so
0ad usr/lib/0ad/libnvimage.so
0ad usr/lib/0ad/libnvmath.so
0ad usr/lib/0ad/libnvtt.so
0ad usr/share/
0ad usr/share/0ad/
0ad usr/share/0ad/data/
0ad usr/share/0ad/data/l10n/
0ad usr/share/0ad/data/l10n/.tx/
0ad usr/share/0ad/data/l10n/.tx/config
0ad usr/share/0ad/data/l10n/ast.engine.po
0ad usr/share/0ad/data/l10n/bg.engine.po
0ad usr/share/0ad/data/l10n/ca.engine.po
0ad usr/share/0ad/data/l10n/cs.engine.po
0ad usr/share/0ad/data/l10n/de.engine.po
0ad usr/share/0ad/data/l10n/el.engine.po
0ad usr/share/0ad/data/l10n/en_GB.engine.po
0ad usr/share/0ad/data/l10n/engine.pot
0ad usr/share/0ad/data/l10n/es.engine.po
0ad usr/share/0ad/data/l10n/eu.engine.po
0ad usr/share/0ad/data/l10n/fr.engine.po
0ad usr/share/0ad/data/l10n/gd.engine.po
0ad usr/share/0ad/data/l10n/gl.engine.po
0ad usr/share/0ad/data/l10n/hu.engine.po
0ad usr/share/0ad/data/l10n/id.engine.po
0ad usr/share/0ad/data/l10n/it.engine.po
0ad usr/share/0ad/data/l10n/messages.json
0ad usr/share/0ad/data/l10n/ms.engine.po
0ad usr/share/0ad/data/l10n/nb.engine.po
0ad usr/share/0ad/data/l10n/nl.engine.po
0ad usr/share/0ad/data/l10n/pl.engine.po
0ad usr/share/0ad/data/l10n/pt_BR.engine.po
0ad usr/share/0ad/data/l10n/pt_PT.engine.po
0ad usr/share/0ad/data/l10n/ru.engine.po
0ad usr/share/0ad/data/l10n/sk.engine.po
0ad usr/share/0ad/data/l10n/sv.engine.po
0ad usr/share/0ad/data/l10n/tr.engine.po
0ad usr/share/0ad/data/l10n/uk.engine.po
0ad usr/share/applications/
0ad usr/share/applications/0ad.desktop
0ad usr/share/pixmaps/
0ad usr/share/pixmaps/0ad.pngLast edited by mpan (2021-01-26 23:08:08)
Paperclips in avatars? | Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
mpan, that is not correct. First, the files database is separate from the normal database and not all repositories have the file list. Additionally, that is only a list of filenames without size information.
Moving the disk space check would basically require adding the .MTREE files from all packages to the repository database.
By the way, apg should know what he is talking about. He is one of the pacman developers.
Last edited by progandy (2021-01-26 23:29:48)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
progandy:
You’re right on the part about not all repos having the files database. I made the mistake of forgeting about unofficial repos.
However, with the rest I must disagree. Indeed the files database contains no information on size, but I referenced it for a different reason: apg has said that before downloading the packages pacman doesn’t know where the space is needed. That is: it doesn’t know the file paths. And the files database delivers exactly that: file paths, before downloading the actual packages.
Paperclips in avatars? | Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Knowing where the space is needed requires both the paths and the sizes. Beyond that, you want to download the files databases on every transaction? No thanks.
Offline