Pacman

Roadmap for version 5.0.2

100% of 10 tasks completed.

Roadmap for version 5.1.0 Expand all | Collapse all

62% of 78 tasks completed. 29 open tasks:

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

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: http://wiki.archlinux.org/index.php/Custom_local_repository#
----CUT---
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.
----CUT---

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#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.

Allan:
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
not.

Xavier:
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
versions)

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).

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


FS#30286 - pacman-key --init hangs at "gpg: Generating pacman keychain mast Expand Collapse
Description:
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
https://bbs.archlinux.org/viewtopic.php?id=138684
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#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:
the
[install]
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:
0) http://www.beroal.in.ua/prg/linux/pacman-part-cache.log
1) with the option "--debug" - http://www.beroal.in.ua/prg/linux/pacman-part-cache-debug.log

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.

https://paste.xinu.at/vm3/
FS#39342 - Output with activated deltas inconsistent Expand Collapse
Hi,

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 modemmanager-1.2.0-2_to_1.2.0-3-x86_64.delta... 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 modemmanager-1.2.0-2_to_1.2.0-3-x86_64.delta... 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#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#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#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 #archlinux-cn@freenode.net) 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 #archlinux-cn@freenode.net, 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-0.3.1.55-1-x86_64.pkg.tar.xz'.
- 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#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
usr/bin/pacman
usr/share/bash-completion/completions/pacman
core/pacman 4.2.1-4
usr/bin/pacman
usr/share/bash-completion/completions/pacman
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
core/pacman

% pkgfile PKGBUILD.vim
core/pacman

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

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


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
usr/share/vim/vimfiles/syntax/PKGBUILD.vim


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

% pkgfile -r 'PKG.*BUILD\.vim'
core/pacman

% pacman -Fs 'PKG.*BUILD\.vim'
core/pacman 4.2.1-4
usr/share/vim/vimfiles/syntax/PKGBUILD.vim

FS#48285 - Download failure message is not accurate Expand Collapse
Usage = Sync
Server = http://sajksdfjklsiowernjkvhasesdfjkhdsaf.com/


error: failed retrieving file 'staging.db' from sajksdfjklsiowernjkvhasesdfjkhdsaf.com : Could not resolve host: sajksdfjklsiowernjkvhasesdfjkhdsaf.com
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/source.sh. 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#49349 - [pacman] --hookdir should have more precedence over HookDir Expand Collapse
Currently in pacman-5.0.1, if HookDir is set in pacman.conf it takes more precedence over --hookdir option. I guess is a more expected bahavior if reverse this.
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
FS#51496 - The makepkg-template testsuite does not run under "make distchec Expand Collapse
SKIP: test/scripts/makepkg-template_test.sh
===========================================

cp: cannot stat '../../test/scripts/makepkg-template-tests': No such file or directory
find: ‘./makepkg-template-tests’: No such file or directory
1..0
SKIP: test/scripts/makepkg-template_test.sh
# All 0 tests successfully run.
FS#53041 - repo-remove does not remove delta's when removing a package Expand Collapse
Description:

repo-remove does not remove delta's for a package with delta's. It leaves behind a .deltas file in the database file throwing the following error when syncing the database:

Additional info:
* package version(s): pacman 5.0.1-4


Steps to reproduce:

- introduce newer versions of package with delta's to a pacman database file
- remove package (repo-remove <db> <package name>)
- The error is visible when syncing the database (error: invalid name for database entry). When extracted the database file shows a .deltas file for the removed package.

The error disappears when doing one of the following:
- re-adding the package (whatever version)
- re-adding the package followed by removing all available delta's and then removing the package.

FS#53770 - emptydirs runs too early Expand Collapse
Summary and Info:

The tidy_remove hooks are run in sorted-filename order. This means that, several other remove hooks are run after tidy_emptydirs (namely, tidy_libtools, tidy_purge, and tidy_staticlibs). Each of these may remove files, making a directory empty; and tidy_emptydirs would like to be able to remove them.

Steps to Reproduce:

Make the 'perl-mldbm' package from AUR. Note that despite the '!emptydirs' being included in options, that there are several empty directories under '/usr/lib'. This is because with the default PURGE_TARGETS value, tidy_purge wipes out every file that perl-mldbm places under '/usr/lib' ('.packlist', and '*.pod')

The obvious solution would be to put "NN-" prefixes on the tidy hook filenames, and give emptydirs.sh a high NN.
FS#57833 - makepkg: lint depends variables Expand Collapse
e.g.

makedepends=('make qt5-tools')

makepkg "handles" this by separating make and qt5-tools. However
--printsrcinfo generates:

makedepends = make qt5-tools

This confuses tools.

linting this variable (and other depends ones) using the same rules as
pkgname would be the ideal solution.

Roadmap for version 5.2.0

0% of 0 tasks completed.

Roadmap for version 6.0.0 Expand all | Collapse all

0% of 2 tasks completed. 2 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#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