Pacman-4.1 Released

Posted in Pacman on by Allan

I have just released pacman-4.1 and packages are now in the [testing] repo. This is the first time I have made a release for any software project, so I was glad to have released a 4.1RC a few weeks back to learn everything that needed to be done.

It has been over a year since the pacman-4.0 release and there have been a large number of contributions made:

$ git shortlog -n -s --no-merges v4.0.0..v4.1.0
   239 Allan McRae
   185 Dan McGee
   158 Dave Reisner
    52 Andrew Gregory
    23 Simon Gomizelj
    20 William Giokas
    19 Florian Pritz
    15 Daniel Wallace
    ...

I win this time! Apart from the usual three contributors, it was great to see other people regularly helping out, both in providing and reviewing patches. A particular thanks to Andrew Gregory who helped me figure out how to fix something on several occasions and has been actively commenting on patches sent to the mailing list. His patch count also puts him in the top ten contributors of all time. In total we have 45 people with patches accepted for this release. Also a big thank you to our translators – particularly because I was learning how the system worked and may have required additional strings to be translated on a couple of occasions…

Moving on to what has changed. There have been quite a number of features added to pacman and makepkg and a couple of new helper scripts in this release.

The major feature for the release is tight integration between the package manager and systemd. After much discussion about how best to perform updates on a rolling release system, we realized that it was essential to have updates preformed with minimal other processes running. Also, the security aspects of updates mean that it is essential that these get provided as soon as possible. We felt the best way to achieve this was to perform updates on shutdown. This is achieved through a new daemon, pacmand that monitors and downloads updates in the background. When updates are found, it schedules a reboot of the system (hence the need to integrate systemd). At the moment the timing of the reboots is not configurable, but a timer will pop-up to allow you to delay it for a preset amount of time. Configuration will likely be added in pacman-4.2, when pacmanctl will be ready for general use. Until that release is made, Arch Linux will minimize the impact by performing all updates in its [testing] repository and only push updates on a yet to be decided day and time of the week. A news post will be made when that is decided.

Of course, all this makes systemd a hard dependency of pacman. We felt this was acceptable given Arch Linux has officially switched to using systemd. As this release is not tested (and unlikely to work) on systems without systemd, Arch users or other distributions using pacman will be required to make the switch to systemd if they want to continue using pacman as their package manager. The integration with system will become tighter in pacman-4.2 where we plan to use the upcoming kdbus message passing interface – through libsystemd-bus – to allow other programs to interact with pacman, making the development of alternative front-ends easier.

In terms of output, there has been improvements in a couple of areas. First colour support was added. This had been floating around for a long time, but no-one had ever spent the time to create a patchset and submit it. I think the colours for a simple update look good, although those when searching are a bit… rainbow. This can be only configured on or off at the moment. Extra informational output has been added for optdepends, providing details about whether an optdepend is installed or not and giving a warning when removing a package that is an optdepend for another. This also provides the groundwork for more complete optdepend handling in future releases.

When building packages using makepkg from this release, information about all the files in the package is stored, including permissions, modification times, sizes and checksums (md5 and sha256), etc. These can be checked using “pacman -Qkk“, excluding checksums (which requires additional support to be added to libarchive in order to read them in). Other useful features include never overwriting .pacsave files, but instead giving them a number suffix as needed. We have also polished the package signature checking, improving key importing and allowing configuration on how to validate packages installed with “pacman -U“, both using local files and from remote sources.

There are a few improvements to package building too. I have covered support for VCS packaging in makepkg previously, with bzr, git, hg and svn packages just requiring an appropriate line in the source array. Also a pkgver() function can be added to automatically update the pkgver variable in the PKGBUILD. With these VCS source lines, or any other source that is volatile, the value “SKIP” can be used in the checksum array.

An optional prepare() function can now be used in a PKGBUILD for preparation of the sources, such as patching and sed alterations. This function is run after the extraction of the sources and not run when --noextract is used, allowing operations that should only ever been run once on the sources to be skipped. Finally, a new debug option is available that will result all the debug symbols that are stripped from binary files to be stored in a separate package, which can be installed to allow easier debugging (another feature that has had patches floating around for a while).

Finally, two new helper scripts have been added to the contrib section: checkupdates and updpkgsums. The checkupdates script allows you to safely check for package updates without altering the system pacman remote databases. The updpkgsums script will perform an in place update of the checksums in a PKGBUILD, although more complex PKGBUILDs (such as those with different sources for each architecture) will not likely work…

So a long post, but this is a big release! There are enough of running the git version that it should be completely bug free, but just in case I am wrong report any issues to the bug tracker.

Edit: Yes – some of this was April Fools… (moderated comments are now restored too).

62 thoughts on “Pacman-4.1 Released”

  1. April 1 pacman on testing you mention pacmand
    men you lie, I subcribe to mailisting and you never mention pacmand neiter pacman-dev nor other mailisting
    aditionally the list of archives that contain pacman not include any pacmand

    this time was SO fast to discover the joke men

  2. > We felt the best way to achieve this was to perform updates on shutdown.
    > This is achieved through a new daemon, pacmand that monitors and downloads updates in the background.
    > When updates are found, it schedules a reboot of the system (hence the need to integrate systemd).
    > At the moment the timing of the reboots is not configurable, but a timer will pop-up to allow you to delay it for
    > a preset amount of time. Configuration will likely be added in pacman-4.2, when pacmanctl will be ready
    > for general use.

    I am super excited about this great new feature. Good work!

    • Absolutely. I was finding it very tiresome having to reboot sometimes several times a day.

  3. Can’t tell if systemd integration is for real, or april fools joke – I don’t trust anything on the internet today 🙁

  4. Another good feature is -n switch on repo-add, which only adds new files to the database.

  5. Nice features. You’ve added the systemd support in commit 2013Apr01 via git commit –stealth?

  6. > Also, the security aspects of updates mean that it is essential that these get provided as soon as possible. We felt the best way to achieve this was to perform updates on shutdown.

    Please tell me this is an Aprils Fools joke or at least that it is optional. Otherwise, those two sentences are not making any sense to me. If it means that you have to restart a server each time a security update comes out, than it is a major complication for administrators.

  7. April’s fool? Hard dependency on systemd and upgrade on rebbot sounded strange to me, absolutely not KISS in my opinion. But looking at PKGBUILD there’s no dependency on systemd nor pacmand in the filelist…

  9. Does this make it possible to complete the /usr merge? …or was it hold back for some other reason? Thanks.

  10. Wait what??. That’s it i am going to install windows 8!! Bye linux!!

  11. Finally I got this great feature of a forced reboot after each update so everything’s clean. I hated my uptime of several days or weeks just because I didn’t found a reason to reboot. Thanks.. love it!

    • I hope pacmand is not mandatory – I never know linux to require a reboot after an update. So what – so I don’t have the latest kernel running until I shut down my system myself.

      I also hope this will not cause something like “please don’t turn off the computer – installing updates” on shutdown. Because this is about the most annoying feature of windows.

      please tell me my worries are exaggerated!

  12. “When updates are found, it schedules a reboot of the system”

    I just hope it will be possible to deactivate this automatic feature ?
    Because not beeing able to handle my system’s updates manually and having automatic reboots will for sure make me stop using pacman.
    I don’t like the analogy, but yes, if in fact this is how it is supposed to happen, the “Windows automatic updates trauma” isn’t far…

    Anyway, thanks for your work. The other features seem very useful.
    Daniel

      • Allan,

        You have replied to trivial questions, but haven’t addressed the issue of automatic shutdown, which is a major issue for many people considering they use Arch and pacman for more control over their system, not less. Could we please have more details on the implementation? For example, will it only request a reboot on kernel updates or on every package?
        I have to agree with people who have compared this to Windows. Their implementation is terrible and to go down that route would be a concern for me.

        Cheers,

        Mike

        • Now the feature is in pacman, we need to decide exactly how to use it in Arch. Expect a follow-up post about this in the coming days.

          • Thanks Allan,

            I’ve been happy with the direction Arch has been going in recent months and I’m sure this will turn out to be another great choice for Arch.

            Mike

  14. “When updates are found, it schedules a reboot of the system”
    Great, this is the one feature which is stopping me from ditching Windows completely. I’d be nowhere without my computer telling me when to go to bed because it needs to update. I take a lot of naps.

  15. There was something fishy about that auto-reboot thingy. So I checked which files are part of the pacman-4.1.0 package.

    Good one Allan 🙂

  17. Finally the awaited auto-reboot function.
    Such a feature deserves a pacman 5.0 instead of 4.1!
    Thank you! =)

    • I think 4.1 is quite fitting. The changes announced in this post aren’t too drastic or dramatic to justify a version bump to 5.0.

      Back on topic:

      Allan you rock! This release is awesome and everything I ever wanted!
      Also congratulations on your first release.
      Keep up the great work.

  18. Some great features there Allan good work.

    I have a few concerns, I use a 3g internet connection out here in South Africa which has 2 bandwidth packages daytime surfer (0500-2300) & night time surfer (2300-0500) this gives me 10 Gb of bandwidth each & after 2300 is when I do all the updates within my house (4 pc’s)
    As the new pacmand will be running 24/7 & downloading/installing/updating/rebooting will we be able to fully control when updates are downloaded/installed?

    Or is this an April fools?

  19. Allan,

    I have to say this is something I’ve always missed since leaving Windows. Its so nice to be working on a long project and have a break forced on me. I get to start all over again and try to remember which programs I had open. Arch will be so complete with this feature. pacmand FTW! I mean, even Ubuntu is pushing updates just before shutdown. Good on ya!.. 😉

  20. Oh, finally, what took you so long to implement this forced reboot feature? Why don’t you listen to your users? Typical you, just like with signed repositories.

    • sorry, I didn’t know, that it was already the second april in your timezone when I posted it.
      Should be an April Fool.

      Why the link: look at the ending: it just queries core

  23. Allan,

    Good job! And auto-reboot is indeed great news! Long have the trauma of not having a fully updated and secure systemd haunted me. Often I wake up and night, sweating and plauged by the thought of a less than recent kernel on my system. With all these mean hackers out there we shouldn’t be too relaxed, I say.

    If not already implemented, I think users need to be prompted with ten minutes intervals after an (important) update and 30 minutes afte an update the system should just force-reboot. I imagine it’s hard to implement so let’s just ask to reboot the system everytime Pacman has been run. Nothing is after all more important than security!

    Oh, and as suggested above a great feature keeping by back from dropping Windows is the update progress tracker when shutting down the system. Please consider adding such a feature.

    Again, my biggest congratulations. This seems like an amazing release!

    –Rasmus

  24. You’ve written about colored output and after merging .pacnew files I’ve seen the option in the config, but how does one obtain the pacman-color binary? rebuilding pacman with some kind of flag?

      • Holy epic fail on my part. I was getting a warning about missing pacman-color binary, turned to be pacaur’s fault. Sorry for the noise

  26. To those worrying about forced shutdowns. I would expect that one could simply disable pacmand and continue running pacman -Syu.

  28. So does 4.10 remove the “SyncFirst” feature you mentioned in the battle of the arch spin-offs that is used by Manjaro?

    Not giving a crap about Manjaro. Just curious.

  29. I’m wondering how many arch users didn’t notice the April Fool parts when coming up to ‘tight integration between the package manager and systemd’. Haha.

  31. Nice work!
    A question about the ‘debug’ option: is it possible to detect within a PKGBUILD that this option is enabled? Some packages may have much more elaborate build systems than can be serviced by simple DEBUG_CFLAGS, e.g. require specifying specific make targets or (in the case of CMake) configuring for a debug build.

      • it sets something like -DCMAKE_BUILD_TYPE=Debug

        but there’s no good way to set that from an env var, afaik

    • Isn’t the debug option set in PKGBUILD therefore you know when you are writing the PKGBUILD if it is enabled or not or if you want to let others enabling it manually you can just look for that option in the option array?

  32. Wow I almost left for Gentoo. My rss reader didn’t cross things out. April Fools on the internet lasts longer than a day…

  33. Thanks Allan, new pacman is better, prettier and works great.

  34. Is there any way to add –depth 1 when using VCS(git) and pacman 4.1?
    Right now i need to download 300+MB instant of 50MB, because i download the whole history. (mesa-git)

  35. Systemd required and a background daemon downloading stuff. I completely dislike this.