Pacman-Undo for package roll-backs

giddie · 2009-11-12 14:10:06

During the upgrade to Xorg 1.7 I had a few issues, and needed to downgrade to 1.6 again for a while. This was a real pain to do manually, and it occurred to me that there really ought to be some kind of script available to help with this. Well, since I couldn't find anything like it on the internet I figured I might as well do it myself, and here it is:

http://github.com/giddie/bits-n-pieces/ … acman-undo
(Click here to get the raw file for download.)

Basically, it presents you with pacman.log in an editor (but with the most recent actions at the top). You choose the actions you want to roll back, and it deals with all the headache of finding the the right version of the package and whatnot. It generates a large "sudo pacman -U ..." command, and a "pacman -R ..." command (if necessary), and prompts you before running them. It's also capable of separating groups of actions, to deal with those situations where the order in which packages are removed & installed is important.

I've already had some good use out of this script---very handy if something breaks and you really don't have the time to fix the issues. It makes it much easier to postpone issues until later.

Last edited by giddie (2009-11-12 14:13:09)

Daenyth · 2009-11-12 14:33:55

Interesting. I had tried to write something a little similar a while back (pacroll I think, check the wiki), but it never really worked right. Maybe you can get something out of it though.

giddie · 2009-11-12 15:38:34

Thanks; I hadn't noticed Pacroll. That's some almighty bash-fu in listupdated! From what I can make out, it's using pretty much the same approach as Pacman-Undo. I think I benefited a great deal from choosing Ruby over Bash though. I do hope something like this makes it into the standard tools someday.

Daenyth · 2009-11-12 16:17:32

Yeah... My bash-fu is normally good, but do note that the script doesn't work right currently, and I lost interest in trying to fix it

Daenyth · 2009-11-12 16:20:42

Also I could have GREATLY simplified that function by using "tac" instead. But I don't think that was the broken part.

xduugu · 2009-11-12 16:38:59

I wrote something similar, but less complex and in bash. It did however not reach a state satisfying enough to make it public yet. Mainly, it lacks several error messages and dependency handling. I thought I could borrow the dependency stuff from your script , but unfortunately you did not implement it either; all packages, also the dependencies, are installed as explicit. Probably, you want to fix that; I think the easiest solution is using pactree from pacman-contrib.

giddie · 2009-11-12 16:46:36

@xduugu => Would you mind explaining what you mean by 'dependency handling'? I think I could do with a use case to grasp the problem that needs solving.

xduugu · 2009-11-12 17:00:23

Let's assume there is a package A which depends on B. You remove package A (-Rs) and the logfile contains the following lines:

[2009-11-12 12:34] removed A (1.0-1)
[2009-11-12 12:34] removed B (1.0-1)

Now, you want to revert this removal and run some tool on the logfile. It will find among others two removed packages A and B, but it does not know that A depends on B. Imo the right way is to install B "--asdeps" whereas A "--asexplicit". Therefore, you need some kind of dependency handling (or dependency discovery) to figure out these dependency relationships.

Last edited by xduugu (2009-11-12 17:01:47)

giddie · 2009-11-12 17:13:51

OK, I see what you're getting at. What happens, though, if both packages were explicitly installed to begin with? I don't think it's a good idea to make assumptions that have even the slightest chance of being wrong. I think that to implement that feature correctly, Pacman needs to provide further information in the log file.

If we really want rollback to be done properly and reliably, it should probably be added directly into Pacman.

schuay · 2009-11-12 20:21:02

I was also thinking about this recently, but more along the lines of 'make a backup of the pacman database before each upgrade, and if something goes wrong restore the backup and downgrade using pacman -Suu'.

Not sure if it would work but it seems simpler than config file parsing

xduugu · 2009-11-12 22:03:17

@guddie: In my opinion, it is better having only the required packages installed as explicit than every. However, your objection is appropriate; dependencies which were installed explicit before their removal might get installed as dependency, but that is only relevant when the explicit installed dependency and the package which depends on it were removed at the same time.

@schuay: It seems simpler indeed, but would considerably increase the upgrade time and is limited to downgrading installed packages (no reinstall/removal of packages).

giddie · 2009-11-13 00:30:27

@xduugu => Oh yes indeed---I certainly agree that it's best to ensure that dependencies remain marked as dependencies My point is that right now, the only 'official' way to downgrade a package is to look at the log, and do a 'pacman -U', which will of course clobber the 'Install Reason' anyway. Until Pacman provides a better way of performing downgrades, the best we can hope for is a dumb script to take the edge off the task.

Daenyth · 2009-11-13 18:35:30

Are you sure using -U changes the install reason?

brisbin33 · 2009-11-13 21:03:55

i believe pacman always assumes explicit unless:

a) you use --asdeps
b) it's being install /by/ pacman as a dep
c) you're reinstalling via -S a package currently installed as a dep (hence the availability of the --asexplicit option)

i.e. -U --asdeps would be needed to keep the "install reason" accurate when reinstalling what was once a dep but now just on a list parsed from a log.

there really seems no solution other then some good ol' manual cipherin'

unless...

rather than holding up the upgrade process, write a small wrapper that runs -Syu /first/. then shoots off a background process to parse the log for the packages you just upgraded, grep through pacman -Qi to see what's a dep and what's explicit, then write a small text file to be used in the event you need to roll back /that/ upgrade. you could keep a timestamped text file for each -Syu and roll them back as needed, in order, keeping the explicit/dep situation intact.

an awful lot of work (and i've never found myself wanting to roll back an entire upgrade, only the occasionally package here and there). but it's a thought...

EDIT: scratch that, i'm thinking of a pacman-undo for only -Syu's; yours is an all-purpose pacman-undo for any operation... oh well. ignore me .

Last edited by brisbin33 (2009-11-13 21:05:59)

giddie · 2009-11-14 15:08:34

Surely it can't be too difficult to patch Pacman to add this information to the log, can it? I'll take a look if I have the time at some point and someone doesn't beat me to it. Although, I wonder if it would make sense to store this kind of historical metadata somewhere outside the log? I don't really know enough about Pacman internals.

Daenyth · 2009-11-14 15:32:47

giddie wrote:

Surely it can't be too difficult to patch Pacman to add this information to the log, can it? I'll take a look if I have the time at some point and someone doesn't beat me to it. Although, I wonder if it would make sense to store this kind of historical metadata somewhere outside the log? I don't really know enough about Pacman internals.

It wouldn't be hard to add, but I don't think it's really worthwhile.. It would make the log file somewhat useless for manual parsing to have a ton of metadata.

giddie · 2009-11-14 17:45:28

Yeah, agreed---hence my thought that it might be better to store this kind of stuff elsewhere. Not quite sure where would be appropriate though.

xduugu · 2009-11-18 23:04:18

To dig this thread for the last time, this is what I currently use:

        declare -a deps exps
        declare -A all_deps
        for pkg in ${to_install[@]}; do
            for dep in $(pactree -l $pkg | sed 1d); do
                all_deps["$dep"]=1
            done
        done
        for pkg in ${to_install[@]}; do
            if [[ -n ${all_deps["$pkg"]} ]]; then
                deps=("${deps[@]}" $pkg)
            else
                exps=("${exps[@]}" $pkg)
            fi
        done
        $PACMAN -U --asdeps ${deps[@]}
        $PACMAN -U ${exps[@]}

It does not preserve the original install reasons but is better than a general --asdeps and sufficient for me.

Arch Linux

#1 2009-11-12 14:10:06

Pacman-Undo for package roll-backs

#2 2009-11-12 14:33:55

Re: Pacman-Undo for package roll-backs

#3 2009-11-12 15:38:34

Re: Pacman-Undo for package roll-backs

#4 2009-11-12 16:17:32

Re: Pacman-Undo for package roll-backs

#5 2009-11-12 16:20:42

Re: Pacman-Undo for package roll-backs

#6 2009-11-12 16:38:59

Re: Pacman-Undo for package roll-backs

#7 2009-11-12 16:46:36

Re: Pacman-Undo for package roll-backs

#8 2009-11-12 17:00:23

Re: Pacman-Undo for package roll-backs

#9 2009-11-12 17:13:51

Re: Pacman-Undo for package roll-backs

#10 2009-11-12 20:21:02

Re: Pacman-Undo for package roll-backs

#11 2009-11-12 22:03:17

Re: Pacman-Undo for package roll-backs

#12 2009-11-13 00:30:27

Re: Pacman-Undo for package roll-backs

#13 2009-11-13 18:35:30

Re: Pacman-Undo for package roll-backs

#14 2009-11-13 21:03:55

Re: Pacman-Undo for package roll-backs

#15 2009-11-14 15:08:34

Re: Pacman-Undo for package roll-backs

#16 2009-11-14 15:32:47

Re: Pacman-Undo for package roll-backs

#17 2009-11-14 17:45:28

Re: Pacman-Undo for package roll-backs

#18 2009-11-18 23:04:18

Re: Pacman-Undo for package roll-backs

Board footer