You are not logged in.
Pages: 1
One package management thing that would seriously make arch a cut above the rest is transactions. You can "roll back" previous pacman -S/ pacman -Suy / pacman -U commands by looking through a history of pacman commands a selecting to undo that specific command. Later versions could let you roll back to specific versions of software or release sets.
Lets say you installed something like gedit (you heard something about making it like textmate) on your non gnome system, and it came up with 50 new dependencies. You go ahead with it and install it, but a month later you decide dont want it anymore. You go pacman -R gedit, where pacman removes the one package. You still have that ugly mess of 50 dependences behind it and you can't uninstall it. While with transactions, you can go back to your "pacman -S gedit" command and it will remove all the packages installed just for gedit.
I know some more details would have to be fleshed out, but what do you think?
Offline
While a true transaction model would be a boon (and has been discussed before, but not actively worked on yet), the use case you've supplied isn't really a proper use of transactions. For that case, you can just remove gedit with pacman -Rsc gedit and it'll clean off those deps for you, while ensuring that it'll keep any that are required by other applications.
Offline
As Travis said, your case isn't a real transaction. You're talking about something different. Transactions take the following form:
begin process
do step 1
if failure, rollback
do step 2
if failure, rollback
...
do step N
if failure, rollback
commit all changesOffline
And, if we were to implement a truly transactional process (assuming a single pacman operation == a single transaction) and add the feature of allowing users to roll back individual transactions, they wouldn't be able to arbitrarily roll them back anyway. If you did:
pacman -S gedit # transaction 1
pacman -S foo # transaction 2
pacman -Syu # transaction 3
If you wanted to roll back the gedit install, you'd have to roll back every transaction after it first, since each transaction may depend on the fact you installed gedit.
For example, say gedit pulls in dependency 'libedit'.
Now, assume 'foo' depends on 'libedit' as well - then pacman -S foo would _NOT_ install 'libedit', since you already had it. At this point, arbitrarily rolling back the pacman -S gedit transaction would break 'foo' - we don't want that!
Also, the pacman -Syu might have updated 'libedit' to a new version. Then what happens if we roll back the gedit install? The 'libedit' that's on our system now isn't the same as the one that was installed by pacman -S gedit -- another problem.
If we wanted to support rolling back, then people would have to first roll back the pacman -Syu, then rollback the pacman -S foo, then rollback the pacman -S gedit.
Last edited by Cerebral (2007-11-08 21:15:12)
Offline
You could probably write yourself a pacman wrapper that does simple transactions. Just have an opposite for every command. Anything with -y in the options list though gets tricky, as you'd have to restore the pacman database to it's previous state... so every pacman -Syu, you'd have to save a copy of the entire /var/lib/pacman.. or at least a diff it and save the diff? I dunno, this is a mildly interesting problem for me...
Offline
Actually, codemac, you should be able to do this with the pacman.log
Offline
With the example of gedit: Isn't this done by using the command 'pacman -Rns gedit'? R removes, obviously, n deletes all configuration files, and s removes the dependencies that are no longer needed. I'm also reminded of yaourt, which has the added functionality to remove all unneeded packages by using 'yaourt -Qt'.
However, I think some kind of added feature like the ability to optionally backup packages would be a great addition. For instance, if there is a program I have been using for months and I've gotten used to it as it, and there is a new version in the repos that has changed in a way I don't particularly like, it would be nice to have the current version backed up so I could revert to it. Usually, just out of habit, I periodically delete my package cache, so my old packages aren't there to fall back on; this would make doing so irrelevant.
Last edited by yomtendok (2007-11-09 03:17:19)
Offline
Pages: 1