removing /var/lib/pacman/local/- made it remember everything. so it's not bust.

>> this could easily be fixed by checking for free space on / before doing anything.

So how much free space is enough?

Sync DBs store the compressed file size, so we can approximate disk requirements after processing a sync list, but we don't know for fact how much space the uncompressed packages will take, and we don't know for fact how much space the DB entries in /var/lib/pamcan/local will take. Once packages are downloaded, we have a definite idea of the uncompressed space requirements for the package (but not the DB).

So I think we're going to need multiple diskspace checks at various points in the package installation process. Once after a sync and before downloading, then again after packages are downloaded and meta-data is loaded. And after all's said and done, we still have to do some guesswork on the DB size requirements.

how much space? checking for more than 0 before installing a package would be a start.

pacman erroring out would help too, it realises there's something wrong with codec's installation, but continues on anyway.

a possible fix: http://www.archlinux.org/pipermail/pacman-dev/2006-July/000404.html

It would be best if the package manager would support full transactions, and if something goes wrong it should be able to rollback... This would require some spare working space, but somehow I feel that's the only way a package manager should operate.

Has anyone tried implementing that? The logic should not be that hard, but I wonder about the performance.

and what would be that logic?

btw have a look at the cvs, transactions are already supported, but for rollback - do the mirrors provides the old versions of packages or what? i don't think so

> do the mirrors provides the old versions of packages or what? i don't think so

they dont need to. they're already installed on your system and you're upgrading from them.

then let's define what does rollback should do:

(imho) the ability of the following: pacman upgrades foo-1.0 to foo-2.0, then i empty the package cache (i'm allowed to do it all the time) then i'm able to downgrade foo-2.0 to foo-1.0

do you still think that they don't need to? :)

Miklos, before you upgrade a package you have all the files of the old package in your filesystem (/usr/bin/foo for ex.).

The idea of a rollback is that, for every destructive operation that pacman does (deleteing, changeing or overwriting any file, including the package meta-data) it would first make a safe copy... if all is good at the end the safe copies are removed. If not, a rollback would bring them back.

This would require spare hard disk space.. but it might be worth it.

ok, so this still won't solve the following situation:

pkg A depends on pkg B which is a library. the library is upgraded and it provides a newer soversion of the library, so that pkg A needs recompiling, but you're a user, so you don't want to compile anything, but till the devs provides a fixed pkg A you want your old version of pkg A back

i thought this is what is rollback about, but this is something totally different :)

>Sync DBs store the compressed file size, so we can approximate disk requirements after processing a sync list, but we don't know for fact how much space the uncompressed packages will take, and we don't know for fact how much space the DB entries in /var/lib/pamcan/local will take. Once packages are downloaded, we have a definite idea of the uncompressed space requirements for the package (but not the DB).

Why not have more package info in the db ? It'd make sense to have all the important info in the sync db (URL, installed size, pkg size, etc.)

see http://www.archlinux.org/pipermail/pacman-dev/2006-June/000398.html

though noone cares about that patch..

This should be fixed in CVS now. Changing status, but keeping open.