Talk:Pacman/Tips and tricks

From ArchWiki
Jump to: navigation, search

Listing changed configuration files

Regarding the shell script to manually list the configuration files that have changed, I wrote the following script instead that only uses awk to process the /var/lib/pacman/local/*/files:

changed-files.sh
#!/bin/sh
cat /var/lib/pacman/local/*/files | awk '
    /^$/ { backups = 0 }
    {
        if (backups) {
            $1 = "/"$1
            if ($2 == "(null)") {
                if (! system("test -e "$1)) {
                    print "d41d8cd98f00b204e9800998ecf8427e "$1
                }
            } else {
                print $2" "$1
            }
        }
    }
    /^%BACKUP%$/ { backups = 1 }
' | md5sum -c --quiet

It supports empty/non-existent files that have (null) instead of a hash but does not list to which package owns a file. --Gdiscry (talk) 03:55, 8 October 2013 (UTC)

Remove everything doesn't work with pacman -Qeq

Removing everything but the base group didn't work for me until I replaced "pacman -Qeq" with "pacman -Qq" without the e. Was it a bad idea to omit the e? Should this be changed in the command on the page? When I didn't omit the e some packages (akonadi and a few others) printed ":: akonadi: requires mariadb" and similar errors and I couldn't remove the packages. Pelzflorian (talk) 16:45, 14 June 2014 (UTC)

I think you should keep the 'e' and you should change the installation reason for mariadb. -- Karol (talk) 17:27, 14 June 2014 (UTC)
Hmm. It wasn't just mariadb, there were also similar messages with libgl and a few (not that many) other packages. Using pacman -Qq worked for me; I'm not sure if it did something it wasn't supposed to. But it's not like I wanted to keep mariadb and the others, so I'm not sure what's wrong about -Qq? Pelzflorian (talk) 20:19, 14 June 2014 (UTC)
Can I assume you're referring to Pacman tips#Removing everything but base group?
  • pacman -Qeq|sort (listA) finds all explicitly-installed packages
  • (for i in $(pacman -Qqg base); do pactree -ul $i; done)|sort -u|cut -d ' ' -f 1 (listB) finds all the installed packages of the base group AND their dependencies
  • comm -23 listA listB (listC) finds all installed packages that are explicitly installed AND are not in base group AND are not dependencies of a package in the base group
  • pacman -Rs listC tries to remove all these packages AND their non-explicitly-installed dependencies
When you ran the command, pacman tried to remove mariadb but akonadi was needing it, and it wasn't on the list, so that was the error.
  • Neither mariadb nor akonadi could be on your listB
  • mariadb or a package that was needing it was on your listA
  • akonadi, instead, wasn't on your listA either, nor there was a package that was needing it
This means that akonadi wasn't installed explicitly, but also there wasn't any explicitly-installed package that was needing it => akonadi was a top-level (orphan) dependency
So yes, the one-liner is buggy, orphan packages can break it. There are some possible ways to fix it, we could add pacman -Qdt to the lists, we could remove everything with pacman -Rsc (but this could leave some orphan dependencies installed), or we could indeed remove the -e option to create listA, and in that case there would be no more point to remove packages with -Rs, and a simple -R should do.
I'm editing the article with the third solution, which seems the cleanest and simplest. Using -Rs, though, didn't do any damage, Pelzflorian, it was just unnecessary.
This is untested, however, so I'm leaving this discussion open for comments.
-- Kynikos (talk) 09:36, 16 June 2014 (UTC)
Thank you for the clarification. I don't know pacman all that well, but I do think it is better if that script works with orphans (I'm sure others have orphaned packages as well) and I'm glad the command I used wasn't all wrong (even if the -Rs could have been an -R). Pelzflorian (talk) 09:42, 16 June 2014 (UTC)