Roadmap for version 5.0.2

100% of 5 tasks completed.

Roadmap for version 5.1.0 Expand all | Collapse all

25% of 44 tasks completed. 33 open tasks:

FS#12536 - pacman should report package versions when conflicts are detecte Expand Collapse

When a repository package conflicts with a local one, it would be very helpful if pacman would report both the versions instead of just reporting the conflict. For example I have libdrm-git installed and today another package requested libdrm to be installed from the repository upon -Syu (Which is a bit odd just like that anyways as libdrm-git is supposed to provide libdrm)

[root@Tachychineta | 14:25:48] # pacman -Syu
:: Synchronising package databases...
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
:: libdrm conflicts with libdrm-git. Remove libdrm-git? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: libdrm: conflicts with libdrm-git
[root@Tachychineta | 14:25:56] #

Problems with this output:
1.) I don't get to know WHY libdrm should be installed (pacman should report why it's a dependency all of a sudden)
2.) I don't get to know which VERSION of libdrm will be installed in contrary to which version my local package is providing (of course I can pacman -Ss libdrm to find this one out)

In my case, "something" needs libdrm to be installed for some unknown reason (as my libdrm-git package provides libdrm libdrm-git libdrm>=2.3.0 libdrm>=2.3.1 libdrm>=2.3 while the libdrm package is 2.3.1-2 and my git package would be perfectly fine.) Knowing which version of the original libdrm pacman wants and to install and which local package is already providing a (maybe) lower version would speed up the problem solving process.

FS#17752 - [repo-add] should have option to prevent downgrading Expand Collapse
according to wiki:
repo-add /path/to/repo.db.tar.gz /path/to/*.pkg.tar.gz

The last argument will add all pkg.tar.gz files to the repository, so be careful. If having multiple versions of a package in the directory, it is unclear which one will take precedence and end up in the repository.

i think that there can be some option to prevent repo-add from replacing newer version with older version of package in repository. or maybe both packages can be added and "pacman -S" will determine which is newer by itself anyway...
FS#17874 - [pacman] bash completion with nonstandard DBPath Expand Collapse
Summary and Info:

The file `/etc/bash_completion.d/pacman` does not respect pacman's `DBPath` variable which is defined in `/etc/pacman.conf`.

Since the `DBPath` is freely selectable everything should work as well as with a standard configuration.

One possible implementation is annexed. So far, it works for me.

FS#18193 - Pacman failed to find unused dependencies Expand Collapse
Linux linux 2.6.32-ice #1 SMP PREEMPT Mon Jan 11 04:50:15 CET 2010 i686 Intel(R) Pentium(R) M processor 1.73GHz GenuineIntel GNU/Linux
Pacman v3.3.3 - libalpm v4.0.3

pacman -Qdt returns too many false positives. (please look at attachment)

[mete@linux ~]$ pacman -Qm
gtkpod-git 20100119-1
ifuse 0.9.5-1
kotaci 0.6-1
libflashsupport-pulse 0-3
libgpod-kmaglione-git 20100119-1
libiphone 0.9.5-1
libplist 0.16-1
limewire 5.4.6-1
mplayer-svn 30226-1
shorewall 4.4.5-1
subtitlecomposer 0.5.3-2
usbmuxd 1.0.0-2
xine-lib-pulse 1.1.17-1

FS#21853 - cb_dl_progress cannot be initialized properly when resuming a fi Expand Collapse
dload.c does
handle->dlcb(filename, 0, ust.size);
even when we are resuming a file at a given offset, because that's the only way to tell cb_dl_progress to re-initialize its counters when we are starting a file download.

There are probably many ways to fix this, just unsure which one to choose :
1) track last filename in cb_dl_progress to detect new files and reset counters
2) add a parameter or abuse existing parameters (e.g. filename == NULL) to tell cb_dl_progress to reset
3) add a new callback function to reset or init a new file download at a given offset
FS#22870 - handle needed before group selection Expand Collapse
Rather than keeping it in my bookmarks, it makes more sense to keep that request in the bug tracker.

Doing a "pacman -S base --needed" processes the --needed after the selection
dialog which is annoying... is that easily changed? It does not matter if

Ah uhm right.
Here is how it works now :
1) alpm_find_grp_pkgs gives to the frontend a list of sync packages,
members of a specified group
2) interactive selection in frontend
3) alpm_add_pkg called on each package, where the --needed check is
done (this means checking for existing local package and comparing

It's definitely possible to add needed check in the backend in 1) or
in the frontend just before 2).
Not sure where it would fit, I will let others decide that and I can
then implement it if needed (no pun intended).

I am really torn between front and backend implementation of this... I think I am leaning towards backend.

FS#23110 - A different pacman --config, points to a wrong mirrolist file Expand Collapse
Summary and Info:

When using "pacman --config" pointing to another pacman.conf, the pacman.d/mirrorlist file used, is not the one expected to be, but the default /etc/pacman.d/mirrorlist.

Steps to Reproduce:

Mount a disk with another arch system in /mnt/disk/, and try to install a package in it:

# pacman --debug --config /mnt/disk/etc/pacman.conf --root /mnt/disk/ -S somepackage

Reading the debug output, one can confirm that /mnt/disk/etc/pacman.conf is not using /mnt/disk/etc/pacman.d/mirrorlist file as it would be expected, but it's using /etc/pacman.d/mirrorlist file (which is the absolute path described in pacman.conf)
This can be a tricky situation if someone is not aware of it.
I think that "pacman --config" should take care of path in pacman.conf Include options, and consider them as relative path.

FS#30286 - pacman-key --init hangs at "gpg: Generating pacman keychain mast Expand Collapse
After running pacman-key --init, the terminal will hang at
gpg: Generating pacman keychain master key
indefinitely with no output to the user.

In this forum post
many users confirm this happening, and a fix being "generating entropy" via running ls -R / in another terminal or by connecting and moving around a mouse while pacman-key --init is hanging. This input should be automated or it should be surfaced to the user that it is required.

Additional info:
* core/pacman 4.0.3-2 (base)

Steps to reproduce:
* with a fresh install of arch, run pacman-key --init
* notice that it hangs after the following output:

[root@(none) ~]# pacman-key --init
gpg:generating pacman keychain master key...

FS#31551 - Allow specifying paths without root prefix for -Qo Expand Collapse
Summary and Info:

When using testing ownership of a file inside an alternative root:
pacman -r /dir -Qo /path/to/file

it is requires that the full path - including the root prefix - is specified. Thus, this will not work:

pacman -r /root -Qo /etc/pacman.conf

We should test if the file is in the root and if not add the directory prefix.
FS#31558 - List file containing $srcdir Expand Collapse
Summary and Info:

makepkg dies a grep of the package files to check for $srcdir and gives a warning like:

==> WARNING: Package contains reference to $srcdir

It would be nice to list the actual file(s) with that issue.
FS#33076 - Misleading message: "Errors occurred, no packages were upgraded" Expand Collapse
When pacman aborts part way through a transation, it print this message, but some packages have been upgraded...
FS#33105 - All conflicts are reported as "conflicting dependencies" Expand Collapse
> pacman -S pacman
resolving dependencies...
looking for inter-conflicts...
:: pacman and pacman-git are in conflict. Remove pacman-git? [y/N] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: pacman and pacman-git are in conflict

Not a dependency in site...
FS#34741 - Improve signature "failure" output Expand Collapse
e.g. with "SigLevel = Required" and an unsigned database:

error: failed to update xorg113 (invalid or corrupted database (PGP signature))
FS#34920 - colorize the optional dependencies output Expand Collapse
Summary and Info:

optional dependencies output:
after the package description isn't bold/colorized

Steps to Reproduce:

install a package that have optional dependencies and you have at least one installed
FS#35789 - "wrong or NULL argument passed" with an incorrect "*.part" file Expand Collapse
Summary and Info:
I guess that in rare cases (e.g. a broken mirror), a "*.part" file may have the size >= the size of the correct package file. In this case, Pacman reports "error: failed to commit transaction (wrong or NULL argument passed)". It neither reports the name of this file nor checks the correctness of this file. When running "pacman -Su", I don't know which file is problematic. Full logs:
1) with the option "--debug" -

Steps to Reproduce:
Let P be some package, V be its latest version.
0. Downgrade P.
1. Rename "$P-$V" to "$P-$V.part" in "/var/cache/pacman/pkg".
2. Run "pacman $P".
3. Observe the error message.

pacman 4.1.1-1
FS#38990 - Clarify IgnorePkg description Expand Collapse
Things not clear from the manual:
- space delimited
- can be specified multiple times
FS#39257 - Well-timed Ctrl-C during download rename makes update fail Expand Collapse
If you manage to Ctrl-C between when 1) libalpm downloads the file and 2) it calls rename, you end up in a situation pacman doesn't know how to get itself out of. Yes, I somehow managed to do this.

To reproduce without needing to win the lottery, simply rename a current sync package file in your cache and tack '.part' on the end. You'll then see that the following happens:

debug: found cached pkg: /var/cache/pacman/pkg/systemd-sysvcompat-210-2-x86_64.pkg.tar.xz.part
debug: using (package - .part) size
debug: setting download size 0 for pkg systemd-sysvcompat
debug: returning error 31 from alpm_db_get_pkg : could not find or read package

Because the download size is set to 0, libalpm gets confused- it thinks the file is fully downloaded (causing it not to be added to the download loop), but the only place things get renamed is inside the downloader.

I tried a quick hack at this, but there isn't an easy solution that I could figure out. I'd suggest maybe doing the rename operation outside of the "is this fully downloaded" check, perhaps? You know best though.
FS#39342 - Output with activated deltas inconsistent Expand Collapse

I use pacman with activated delta option. I think the output is a bit inconsistent. When pacman applies the deltas there is neither a progress bar nor a numbering of the packages. Sorry, I forgot to create the messages in english; but you should be able to understand the problem anyway.

:: Installation fortsetzen? [J/n]
:: Empfange Pakete...


Prüfe Integrität des Deltas...
Wende Deltas an....
Erstelle modemmanager-1.2.0-3-x86_64.pkg.tar.xz mit Erfolgreich!
(8/8) Prüfe Schlüssel im Schlüsselring
(8/8) Überprüfe Paket-Integrität
(8/8) Lade Paket-Dateien

Maybe it should look like this:

:: Installation fortsetzen? [J/n]
:: Empfange Pakete...


(1/1) Prüfe Integrität des Deltas...
:: Wende Deltas an....
(1/1) Erstelle modemmanager-1.2.0-3-x86_64.pkg.tar.xz mit Erfolgreich!
(8/8) Prüfe Schlüssel im Schlüsselring
(8/8) Überprüfe Paket-Integrität
(8/8) Lade Paket-Dateien
FS#43586 - "invalid or corrupted package" - pacman should explicitly say wh Expand Collapse
Total Installed Size: 1044.97 MiB
Net Upgrade Size: 237.14 MiB

:: Proceed with installation? [Y/n]
(328/328) checking keys in keyring [####################################################] 100%
(328/328) checking package integrity [####################################################] 100%
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

I probably can use --debug and find which package is corrupted, but that's extremely sub-optimal.

pacman should explicitly say what package(s) are corrupted.
FS#43706 - [checkupdates] Avoiding using the 'eval' command Expand Collapse
The 'eval' command is risky to use when what is eval-ed is not under the developer control.
That is the case here with this line:

eval $(awk -F' *= *' '$1 ~ /DBPath/ { print $1 "=" $2 }' /etc/pacman.conf)

If a maligned man adds a bad command at the end of a 'DBPath=' line, like:

DBPath = /var/lib/pacman/;rm ...

the 'rm ...' will be executed by the 'eval' command, which is bad.

I submit a patch to correct this, which avoids the 'eval' command and secures the script:

FS#44850 - [paccache] prints success message even if no packages were remov Expand Collapse
I ran paccache w/o sudo and used ^C to quit when asked for password. I got an error ... and a success message:

$ paccache -r
==> Privilege escalation required
[sudo] password for karol:
==> ERROR: Unable to escalate privileges using sudo

==> finished: 23 packages removed (disk space saved: 154.37 MiB)
$ paccache -d

==> finished dry run: 23 candidates (disk space saved: 154.37 MiB)
$ sudo paccache -r

==> finished: 23 packages removed (disk space saved: 154.37 MiB)
$ sudo paccache -r
==> no candidate packages found for pruning

$ paccache --version
paccache 4.2.1
Copyright (C) 2011 Dave Reisner <>
FS#45774 - pacman testsuite fails when /tmp is mounted noexec Expand Collapse
We require various things to run during testsuite. /tmp mounted noexec prevents this.
FS#45831 - Improper parsing of pacman.conf in pacman's various scripts. Expand Collapse
Summary and Info:
pacman's various scripts, such as pacdiff, parses /etc/pacman.conf in such a way, it can confuse comments and other stuff mentioning variables by their name with actual variables. It can cause confusion if one uses custom values in pacman.conf's variables.

Steps to Reproduce:
Have custom variables in pacman.conf, such as DBPath. (i.e. DBPath="/mnt/Storage/.pacman/db/" )
Have the original line commented out for future reference, in a line before the real variable. (i.e. #DBPath="/var/lib/pacman/"), or any other lines containing the variable name.

"pacdiff" for instance, on line 191:
eval $(awk '/DBPath/ {print $1$2$3}' /etc/pacman.conf)

This line will pick out all lines it finds that contains "DBPath", no matter if it's commented out or not, resulting in eval to fail.
This will leave DBPath within the script empty, despite it being set in /etc/pacman.conf, and rest of the scripts reverts back to the default path.

To fix:
I've created a simple patch for pacdiff: pacdiff.patch
See attached files.

The other scripts using the same eval-awk parsing method should also be updated.
It would be preferred if the pacman.conf parsing was done with pacconf instead.
FS#46077 - [pacman] doesn't always tell which package is the one you own Expand Collapse
Summary and Info:

I just got this:

  resolving dependencies...
  looking for conflicting packages...
  error: unresolvable package conflicts detected
  error: failed to prepare transaction (conflicting dependencies)
  :: akonadi-qt4 and akonadi are in conflict

..which is great, but it never tells me which one is the new package (akonadi-qt4), and which is the one I have (akonadi).

Is it the same message when both are installed?
FS#47024 - paccache doesn't support multiple CacheDir's from pacman.conf Expand Collapse
Summary and Info:
/etc/pacman.conf supports multiple CacheDir's
paccache supports multiple --cachedir's on the command line
But if no --cachedir's are specified on the command line, paccache only reads the first CacheDir from /etc/pacman.conf
I would expect that paccache would default to using all CacheDir's in /etc/pacman.conf

Steps to Reproduce:
1) edit /etc/pacman.conf, adding more than 1 CacheDir
2) run paccache without using --cachedir options

FS#47627 - pacman's 'import key' prompt does not stop installation from fai Expand Collapse
Summary and Info:

When installing a package with a never-imported key, pacman (uh, well, libalpm _alpm_key_import) will ask the user if the key should be imported. However, it still does not trust the imported key which (according to quininer (via tox tunnel) at is responsible for a following "'<FILENAME>': invalid or corrupt package (PGP sig)" error.

If this is really caused by the key being untrusted, then pacman should use another message like `Signature from untrusted key blah blah .. continue?' instead of telling the user the package is broken.

I am not quite an Archlinux user, and some extra verification should be used on this report to make sure both quininer and I aren't wrong. @LastAvengers (via telegram tunnel) reported this error to quininer in, so you might be able to get extra info from them.

Steps to Reproduce:

1. Install a random package from third-party sources like archlinux-cn's. In this case the package filename appears to be 'ydcv-rs-git-'.
- In this case, the imported key wasn't able to get enough trust from the Web of Trust. A prompt should be added anyway.
2. Pacman should now ask you if you want to import the key. Y.
3. BOOM.

FS#47943 - busybox du does not support --apparent-size Expand Collapse
busybox does not support GNU du's --apparent-size argument.
This causes a failure to build a package (du fails, which causes an infinite loop).

This has come up before:

Currently, the lack of support in other implementations means that this is worked around in the configure script.
Relevant commits/code:;a=commitdiff;h=cf3341fe591293a493bc925e0433a1f696b37d90;hp=8b367d4441ba85b5548285d987afcfc84c4fcb3e

Currently I can workaround this issue by removing the --apparent-size argument.
FS#47948 - [pacman] Make -Fs behave like -Ss and output group-membership an Expand Collapse
Summary and Info:

It would be handy if -Fs could also output the groups that a package is a member of and whether it is already installed (perhaps even the version that is installed).
Analogous to -Ss:

$ pacman -Ss pacman
testing/pacman 5.0.0-1 (base base-devel) [installed]
A library-based package manager with dependency support
core/pacman 4.2.1-4 (base base-devel) [installed: 5.0.0-1]
A library-based package manager with dependency support
core/pacman-mirrorlist 20160124-1 [installed]
Arch Linux mirror list for use by pacman

Compared to the current(5.0.0-1) output of -Fs:

$ pacman -Fs pacman
testing/pacman 5.0.0-1
core/pacman 4.2.1-4
FS#47949 - [pacman] Suggested pacman -F UI changes Expand Collapse
These are my opinionated changes to the semantics of pacman -F to more closely
follow pkgfile allowing additional operations to be removed.

I present only three changes and demonstrate the ideal output from pacman -F
with a pkgfile example as a reference. The use of -q, -l or -y is unchanged.

1) pacman -F should mimic pkgfile with no arguments specified

% pkgfile /usr/share/vim/vimfiles/syntax/PKGBUILD.vim

% pkgfile PKGBUILD.vim

% pacman -F /usr/share/vim/vimfiles/syntax/PKGBUILD.vim
core/pacman 4.2.1-4

% pacman -F PKGBUILD.vim
core/pacman 4.2.1-4

2) pacman -Fo shouldn't need to exist

As demonstrated with pkgfile one can supply a path and get the owner without
needing a separate option to search for paths.

% pacman -F /usr/share/vim/vimfiles/syntax/PKGBUILD.vim
core/pacman 4.2.1-4

3) pacman -Fs should mimic pkgfile -r and -x shouldn't exist

% pkgfile -r 'PKG.*BUILD\.vim'

% pacman -Fs 'PKG.*BUILD\.vim'
core/pacman 4.2.1-4

FS#48144 - [pacman] unrequired packages query bug Expand Collapse
pacman -Qtd gives a list of only direct dependencies, and pacman -Qttd gives both direct and optional dependencies.
It's the opposite of what the manpage says.
Same applies to -Qte and -Qtte.

FS#48285 - Download failure message is not accurate Expand Collapse
Usage = Sync
Server =

error: failed retrieving file 'staging.db' from : Could not resolve host:
error: failed to update staging (download library error)

That is not a download library error - that URL does not exist...
FS#49076 - Extendable source protocols Expand Collapse
It would be useful to be able to just drop in a file in /usr/share/makepkg/source/ to add support for a new protocol in makepkg. libmakepkg is close to supporting this already, but it currently hardcodes the supported extraction methods in /usr/share/makepkg/ Instead this should probably try to use any matching file in the source directory first, and then fall back to the file one if it didn't find another specific one.
FS#49377 - Better warning message when skipping duplicate targets Expand Collapse
> pacman -S glibc glibc
warning: glibc-2.23-4 is up to date -- reinstalling
warning: skipping target: glibc

Roadmap for version 6.0.0 Expand all | Collapse all

0% of 3 tasks completed. 3 open tasks:

FS#9694 - Universal transaction Expand Collapse
I mentioned this several times on ML, this task is a reminder and a place to discuss it.

So briefly, it would be nice if user could do the following in ONE command (== in one transaction):
* select some packages to install (-A/U)
* select some packages to remove (-R)
* select some packages to sync (-S)
* apply dependency/conflict resolving and replaces checking on request

Note: the current -S can already do all of these (except  FS#9088 ), so this is mainly a code refactoring request.

+ automatically  FS#9088 ,  FS#5798  and  FS#3492 
+ currently manual replaces is quite hackish: '-Rd foo then -U/S bar' is dangerous; '-S/U var then -R foo' doesn't work always (foo and bar doesn't conflict, but fileconflict) and isn't intuitive at all; doing this cleanly in one transaction is nice
+ we could focus to one transaction instead of three type of them (and the hard-to-follow transaction branch in case of sync)
- getopt() limitation

FS#25568 - support listing expanded directory names Expand Collapse
I would like a pacman option that outputs all expanded, defined repositories.

It's easier to explain with an example:
If you have this config:
Include = /etc/pacman.d/mirrorlist

I want something like:
$ pacman --listrepos
core /repo/core/i686
testing /somedir/testing/i686
community /etc/pacman.d/mirrorlist

Why? In AIF i track repositories in their unexpanded form (with variables, so that pacman can expand them correctly), but in AIF I also need to configure CacheDirs for pacman, in which these variables make no sense, so I want the expanded forms.

FS#43484 - Symbolic usernames in package Expand Collapse
Summary and Info:

Since you are checking file owners and mode setted in the packet agains the files installed on disk you should provide a way for symbolic username packing in PKGBUILD. I found a couple of packets which raise 'warning: directory ownership differs on ...' when updated (e.g. murmur, 16. JAN 2015). This happens when a user gets created on post_install() and direcotires in the packet (workdirs) are chown'ed to the newly created user. In this case the PKGBUILD can not know the exact uuid of the user on the target system but only a symbolic name. For further reading see attached chatlog.

Steps to Reproduce:

sudo pacman -S murmur
sudo pacman -S murmur

Text Version