Pacman-5.1 – Don’t Use the Force, Luke!

Wow… look at all the cobwebs around here! No posts in two years. But the need for a pacman release post has dragged me back. I clearly still remembered the password, so that is a bonus!

As is tradition, before I get in to details, I need to thank everyone for their help in making this release. Here are the top 10 committers:

$ git shortlog -n -s v5.0.0..v5.1.0
    82  Allan McRae
    60  Andrew Gregory
    45  Eli Schwartz
    16  Ivy Foster
    10  Dave Reisner
     9  Christian Hesse
     9  Gordian Edenhofer
     8  Alastair Hughes
     7  Rikard Falkeborn
     6  Michael Straube

(I win!) Lots of new names there which is always really appreciated. And as usual a long tail of contributors submitting the occasional patch – there were 48 contributors in total.

Onto what has changed in this release. There is a lack of what I would call a killer feature in this release. Mostly a lot of small changes that improve usability, which is why there was so much time between releases. Here is a detailed list of changes. However, there are a few things worth highlighting.

There is a new option --overwrite, which is a replacement for to often misused --force (hence the release name). This allows fine grained control of what files pacman is safe to ignore conflicts with. Handling the latest upgrade requiring user intervention in Arch Linux would now look like:
pacman -Syu --overwrite usr/lib/libmozjs-52.so.0You can even use globs when specifying the files to overwrite. Not only is specifying exact files to overwrite a lot safer than the old --force, there are also some common sense restrictions there too (you can’t overwrite a directory with a file, or force package installs with conflicting files).

We have also added a --sysroot option that will replace --root. Basically, this now works the way people will expect – for example, the configuration file used is the one in the specified root, and not the local one. This does require a bit more setup while creating a new install root, but hopefully will be a lot more robust.

We have also added support for reproducible builds. This was mostly ensuring all files had the same timestamp and obeyed the SOURCE_DATE_EPOCH standard. We also added a .BUILDINFO file within each package, recording information about the environment a package was built in. This allows scripts to regenerate the build environment to demonstrate a package is reproducible (particularly important in rolling release distros).

There was also improved support for debugging packages. Split packages now produce a single debug package instead of one for each split package. This makes it easier to get all required debug symbols for a particular package (and hopefully easier for distros to carry these packages…). Also, we include relevant source files in the debug packages, allowing us to step through the code.

Finally, I killed off the “contrib” directory as it was taking excessive amounts of pacman developer time. That means no more checkupdates, paccache, … However, this has been picked up as a separate project, which is available by installing pacman-contrib in Arch Linux.

As always, this is a bug free release. But if you spot something you think is a bug, please file a bug report and we can assign blame – which is more important than fixing! (The pool for developer who created the first pacman bug of this release is still open at the time of posting.)

9 thoughts on “Pacman-5.1 – Don’t Use the Force, Luke!

  1. This release breaks yaourt
    package-query: error while loading shared libraries: libalpm.so.10: cannot open shared object file: No such file or directory

  2. what about the gnupg directory creation on fresh installation with your new option –sysroot? Pacman-key do not provide the option to init the gpg key onto alternative system root. So you need to chroot the system and launch pacman-key on it. Ok but the system is not installed yet… and obviously is not possible to run pacman-key, the loop is looped.
    What the solution?
    Please do not answer me :”desactive signature on your pacman.conf”
    I can, for example, copy the whole signature from the host but this manner to process go against the philosophy of the new –sysroot option. I mean, this change was made to provide the possibility to use pacman with the configuration file of the chrooted system.

  3. i forgot the options –gpgdir for pacman-key, sorry for that.
    Anyway even if the /etc/pacman.d/gnupg exist and initialized/populated with pacman-key, the error persist :
    warning: Public keyring not found; have you run ‘pacman-key –init’?
    error: GPGME error: Invalid crypto engine

    • Hrm… I’ve seen this work! It is rather hard to debug from blog comments, so perhaps try the IRC channel or forums for more support.

  4. I’m trying to fix a package that has many conflict files that I’m sure I want to override. Tho, trying to use globbing with `–overwrite` quickly leads to it being unable to execute because the argument list is too long.
    How ironic, the very first time I legitimately need the –force option is when it’s removed. xD It would be nice to still allow complete overwrite for a simple package when forbidding it for `-Syu` for example, or for anything concerning more than 1 package. I dunno, that’s just a thought anyway.

    • Oh and I wanted to add I like the change to something sane and useful! It’s just that I’m facing a specific edge case. 😛