Pacman-4.2 Released

Posted in Pacman on by Allan

I released pacman-4.2 on the 19th of December – which is only marginally after the end of August as originally planned… We had 52 contributors provide patches to this release. Andrew takes the prize for most commits. Here are the top 10:

$ git shortlog -a -s -n v4.1.0..v4.2.0
   164  Andrew Gregory
   139  Allan McRae
    66  Dave Reisner
    26  Jason St. John
    20  Florian Pritz
    18  Pierre Neidhardt
    15  Olivier Brunel
     9  Jeremy Heiner
     9  Jonathan Frazier
     8  Dan McGee

The real prize goes to the person who caused the first reported bug. That could have been Dave but he caught it just in time. And I mean just! I posted to IRC “any ideas for the tag message” and the response I got was “I think I broke updpkgsums“. The shame of being first is inversely proportional to your commit count. (The small typos discovered so far do not count…)

Packaging Changes
There has been a couple of useful features added to makepkg. The main ones are:

Architecture Specific Fields: The source and depends (and related fields) now can all specify architecture specific values. For example:

source=("http://example.com/foo-$pkgver.tar.gz")
source_i686+=("http://example.com/bar32-$pkgver.tar.gz")
source_x86_64+=("http://example.com/bar64-$pkgver.tar.gz")

The source for a given architecture is used in addition to the global source. The ‘+=‘ when specifying extra sources for an architecture does nothing different than just using ‘=‘, but I use it to serve as a reminder that these are additional values. Thanks to Dave!

Templating PKGBUILDs: Many PKGBUILDs share a similar build system, making them highly redundant. This is an attempt to reduce the redundancy by providing a template system. The easiest way to describe this is using an example, so I will use a potential perl module template. We create a file /usr/share/makepkg-template/perl-module-1.0.template. In this file is the build(), check() and package() functions and any common biolerplate. As this is our current version, it is also symlinked to perl-module.template. In our PKGBUILD, we would add:

# template input; name=perl-module;

and run makepkg-template. Now look in the PKGBUILD and you will see that line is replaced with:

# template start; name=perl-module; version=1.0;
build() {
...
# template end;

If we ever need to update the template, we create perl-module-2.0.template and update the symlink. Now run makepkg-template -n to update the PKGBUILD. Read “man makepkg-template” for more details. Thanks to Florian!

Incremental VCS Builds: Previously makepkg would remove its working copy of the VCS source directory before starting a new build. Now makepkg will just update the source copy (or attempt to in the case of SVN…) and build the package. This brings VCS builds in line with those using non-VCS sources. A new option -C/--clean was added to makepkg to remove the old $srcdir before building for cases where incremental builds fail. Thanks to Lukáš (and sorry it took me so long to deal with your patches)!

Source Package Information: To avoid things like the AUR attempting to parse bash to display information from a source tarball, we now provide a .SRCINFO file in an easily parseable format. Thanks to Dave!

Package Functions are Mandatory : The use of package() functions in PKGBUILD was introduced a long time ago. Now it is mandatory that a PKGBUILD has one (with the exception being metapackages that do not have a build() function either). Now that fakeroot usage is limited to the packaging step, the use of fakeroot is mandatory and building as root is disabled.

Misc. Changes: Other things of interest:

  • Static libraries are only removed with options=('!static') if they have a shared counterpart
  • Source signatures are required to be from a trusted source or listed in the validpgpkeys array. We also support kernel.org style source signing
  • Split packages can no longer override pkgver/pkgrel/epoch as that was a silly idea…

Pacman Changes

No we don’t have hooks… They are strongly planned for the next release.

Directory Symlink Handling: Example time! Arch Linux has a /lib -> /usr/lib symlink. Previously, if pacman was installing a package and it found files in /lib, it would follow the symlink and install it in /usr/lib. However the filelist for that package still recorded the file in /lib. This caused heaps of difficulty in conflict resolving – primarily the need to resolve every path of all package files to look for conflicts. That was a stupid idea! So now if pacman sees a /lib directory in a package, it will detect a conflict with the symlink on the filesystem. If you were using this feature to install files elsewhere, you probably need to look into what a bind mount is! Note that this change requires us to correct the local package file list for any package installed using this mis-feature, so we bumped the database version. Upgrade using pacman-db-upgrade. Thanks to Andrew!

Added an –assume-installed Option: I believe this options was invented during a perl update. Almost all compiled perl modules have a dependency on a specific perl version. So with a major perl update, all the modules need to be updated at the same time, or you can use -d to ignore dependency versions, but for all packages and not just perl. This is not a problem with the Arch repositories where all packages are updated at the same time, but if you have lots of perl modules from the AUR, you will need to remove those, update, then rebuild them. Instead you can use --assume-installed perl-5.18 and all those packages depending on perl=5.18 will not complain. Thanks to Florian!

Repository Usage Configuration: A new configuration keyword was added for repositories – Usage. It can take values Sync, Search, Install, Upgrade, All. For example, I have the [staging] and [multilb-testing] repositories in my pacman.conf with the Sync usage. That way I can look at what is in these repositories without using them for package updates. Thanks to Dave!

Mics. Changes: Other changes to pacman:

  • Improved dependency ordering – the dependency ordering did not go deep enough into the tree to ensure correct installation order.
  • A warning is printed if a directory on the filesystem has different permissions to the one being “installed” from the package.
  • Lock files should now never be left behind…
  • Various speed-ups, memory leak plugs and bug fixes

See here for a more complete list of changes.

And I have just realized that the only major change I contributed was the requiring of package() functions, which I am told means 1/3 of the AUR will not build! It feels good to be back to breaking things…

42 thoughts on “Pacman-4.2 Released”

  1. Hi!

    Thanks for the great update! I have a question about the Architecture Specific Fields feature: will it work only with i686 and x86_64 or other architectures are also supported? I am maintaining couple of packages in AUR which are working for ARM as well, so just curious if something like
    source_arm+=(“http://example.com/bar-arm-$pkgver.tar.gz”)
    will work? Thanks!

    • That will work (provided that is the CARCH value in the ARM machines makepkg.conf)

  2. Does checksums field also have Architecture Specific Fields? I use md5sums_x86_64 and md5sums_i686 together with source_x86_64 and md5sums_i686, but I get an error.
    For example, in PKGBUILD is:
    source_x86_64=(64.tar.gz)
    source_i686=(86.tar.gz)
    md5sums_x86_64=(f0e4***4775)
    md5sums_i686=(bd0a***58e6)
    and I got this when makepkg it:
    ==> Validating source files with md5sums…
    64.tar.gz … Passed
    ==> Validating source files with md5sums…
    86.tar.gz … NOT FOUND
    ==> ERROR: One or more files did not pass the validity check!
    makepkg didn’t download the file “86.tar.gz” but validate it (my arch is x86_64).
    Did I make a wrongly use and how can I do?

    • That should work… and in fact, copying exactly what you posted works for me.

      • Sorry, I did’t speak clearly. Build is no problem, but ‘makepkg –source’ gave that error.

  3. I use arch linux on my android devices in a chroot (as well as pc/laptop), The android linux kernel doesnt have “SYSV IPC support” so it cant use fakeroot (http://archlinuxarm.org/forum/viewtopic.php?t=5613&p=31701), therefore i cant build packages unless I use “makepkg –asroot”.

    I know arch linux doesnt support arm and probably doesnt support an android x86 chroot, but is there any chance of bringing that option back, or do u have an idea on how i could bypass it.

      • Thanks for the answer. I ended up creating a bash script that calls “proot -0 $@”, nameing it fakeroot, and putting it first in my “PATH”. This will almost certainly break if pacman uses any command line options for fakeroot in the future.

        Your way is probably better but I would rather not have to have to compile fakeroot and manually update it each time or use my hack on all of my devices.

        Does fakeroot get updated much? Does pacman use any
        command line options when calling fakeroot, will it in the future?

        Does removing the “–asroot” option clean up alot of code? If it would be simple to keep it would be nice to have in my situation, and I imagine there must be a few other people who rely on it.

        You could definitley put a big “NOT RECOMMENDED” in the man page for it because I know we really shouldnt be using makepkg as root. But if you have root access u should be able to whatever you want right.
        “rm -rf $( ls / | shuf -n1 )” is always fun to test out your backups 😉

        • You should not have to update fakeroot yourself. If fakeroot with the sysv IPC does not work, but the TCP one does, your distribution should be changing it. But fakeroot is not updated much anyway.

          Removing –asroot cleaned up substantial code complexity. Your hack should work indefinitely.

          • Thanks for the replies.

            If it cleaned up the code then its worth it, i thought it might’ve been a few lines, this probably wont effect many people and there are simple workarounds.

            The problem with fakeroot is it works fine on most arm computers, probably all that archlinuxarm.org supports, but not running in a chroot on an android tablet/phone, something to do with the android kernel i think. So i doubt archlinuxarm.org will change it. Nobody but me seems to care, even though it breaks building from the aur on android.

    • I also need makepkg –asroot to function for a build script, please revert.

        • I need –asroot as well….because its my prerogative to run as root on MY system. Really…I’m the only user. I shouldn’t need to create multiple accounts for myself. Put the option in the config file and let people choose to re-enable the old functionality.

  4. Hi

    is possible add “{make,opt,}depends_{i686,x86_64}=()” like a new arch sources?

    to avoid code like this:

    if [ “${CARCH}” = ‘i686’ ]; then
    depends+=(‘libxi’ ‘libxft’ ‘libpng12’ ‘libxinerama’ ‘libjpeg6’ ‘xerces-c’)
    elif [ “${CARCH}” = ‘x86_64’ ]; then
    depends+=(‘lib32-libxi’ ‘lib32-libxft’ ‘lib32-libpng12’ ‘lib32-libxinerama’ ‘lib32-libjpeg6’ ‘lib32-xerces-c’)
    fi

    greetings

  5. :: Synchronizing package databases…
    core is up to date
    extra is up to date
    community is up to date
    archlinuxfr is up to date
    :: Starting full system upgrade…
    :: Replace mesa-dri with extra/mesa? [Y/n]
    resolving dependencies…
    warning: dependency cycle detected:
    warning: harfbuzz will be installed before its freetype2 dependency
    looking for inter-conflicts…
    error: failed to prepare transaction (could not satisfy dependencies)
    :: package-query: requires pacman<4.2

    How to solve this error?

    • By removing the [archlinuxfr] repo and uninstalling yaourt and package-query

  6. makepkg –asroot also here!
    if you don t want to use fakeroot, just use an other solution, but please don t kill root user

  7. Seriously? I thought yaourt was poorly written, but I never thought it was that bad.

    These tools should drop privileges when building packages. If not, it is a massive security risk to your system.

  9. Lack of –asroot is a major problem for me – I would like to ask that you reconsider.

    I use makepkg to build packages on arm devices which only have a root user – this is all scripted and no longer works… I can see the benefit of avoiding this on a desktop, but on embedded devices where there is a minimal install, using arch with aur source based distribution of custom packages been really useful.

    This has broken all my stuff: https://github.com/SqueezeOnArch/soa-aur

    • You will have a nobody user. Just drop privileges to that user and run makepkg..

      • Just thought the same. You could also create a special user for building packages.

  11. Btw, what kind of “hooks” exactly are planned for the next release?

    For example, I’ve long thought that it would be nice if the ‘gtk-update-icon-cache’ package could install a hook for running itself, which would automatically fire after package upgrades that touched files in /usr/share/{icons,pixmap}. And another hook for running `fc-cache` after package upgrades that touched files in the system font directories. And so on.

    The benefits would be:

    1) No more need to accompany every single PKBUILD that install icons/fonts/etc., with a install script.

    2) If multiple packages were upgraded, the hook(s) would only need to fire once, at the end. Big system upgrades (e.g. after a new KDE version was released) would probably require significantly less time and disk usage.

    Is this the kind of hooks that you were refering too?

  13. Hi,

    don’t get me wrong, most of my scripts start with something similar to

    if [ “$(id -u)” = “0” ]; then printf “\nDon’t run this script as root :).\n\n”; exit 1; fi

    However, to claim that software using an option of makepkg is super-bad, because it does use this option and to quote an opinion from folks using another distro, especially if it’s unrelated to backwards compatibility, doesn’t make a wrong decision a good one.

    If our software is old, we notice some mistakes and it’s good not to continue a mistake. Anyway, revised software should be backwards compatible as much as possible. To drop an option, or even just renaming an option is a bad idea.

    I guess dropping ‘–asroot’ isn’t a big issue. It’s ok, but consider to keep other software really backwards compatible. It shouldn’t become a fashion to ignore backwards compatibility.

    Happy New Year!
    Ralf

  14. Quote: “Static libraries are only removed with options=(‘!static’) if they have a shared counterpart”

    Got the pre 4.2 Option renamed? Or is it still ‘staticlibs’ and this is a new option? Just asking because the latest makepkg.conf lists this still as ‘staticlibs’