Pacman

Roadmap for version 5.2.2

100% of 7 tasks completed.

Roadmap for version 6.0.0 Expand all | Collapse all

45% of 40 tasks completed. 22 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#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#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#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#38990 - Clarify IgnorePkg description Expand Collapse
Things not clear from the manual:
- space delimited
- can be specified multiple times
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



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#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#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#59595 - failed to initialise alpm library: misleading error Expand Collapse
Summary and Info:

When failing to initialise alpm, pacman seems to always generate the message:

error: failed to initialise alpm library
(could not find or read directory: <dbpath>)

This happens even if the dbpath is unrelated to the error

Steps to Reproduce:

pacman --root /does/not/exist --dbpath /var/lib/pacman/

FS#61497 - Add a timestamp file to repos Expand Collapse
Even with signed repos (come on Arch!), people could delay updates to keep vulnerabilities from being fixed.

Our repos should contain a .TIMESTAMP file, that pacman reads. Then a config option that gives the maximum amount of time a repo is considered valid for.
FS#65677 - [makepkg] not all source files get included in debug packages Expand Collapse
Summary and Info:

We currently only look at the .debug_info section of readelf's output, finding DW_AT_name/DW_AT_comp_dir pair to grab file names. That gets the main compilation units, but misses header files. Header files can contain small functions, and so would be useful in debugging.

We can additionally look in the .debug_line section. This section has a table of directories that source files come from (which can be filtered to remove system directories), and a file name table with files from each directory. This does not include the files we currently grab.


FS#65951 - pacman search results do not match the manual page for --search Expand Collapse
Description:
There was a discussion at https://bbs.archlinux.org/viewtopic.php?id=253813.
pacman manual page states that --search, both for -Qs and for -Ss, is for names or descriptions that match regexp. Users who know that Name and Description are defined fields for each package might expect that only those fields will be searched in. Which is not the case. I think the manual page should use other words than name and description.

Additional info:
* pacman 5.2.1-4

Steps to reproduce:
for pacman -Qs pan, ncurses is probably one of the results. Even though pacman -Qi ncurses | grep pan shows it is included because of the Provides field. ncurses provides libpanelw.so.
FS#66340 - [pacman] distcc and ccache together break gcc in package() Expand Collapse
Description:
When using both distcc and ccache, PKGBUILDs that execute gcc in package() fail to build with an error from distcc like:

distcc[52016] (main) CRITICAL! distcc seems to have invoked itself recursively!

Additional info:
* The cause is that CCACHE_PREFIX is set to "distcc distcc" instead of just "distcc", which is because buildenv gets set once for build() and a second time for package() and each time it appends "distcc". So ccache invokes "distcc distcc gcc" and that causes distcc to have a fit.
* I posted a patch at https://lists.archlinux.org/pipermail/pacman-dev/2020-January/023949.html but it wasn't taken in. I ran into this again just now so I decided to file a bug.

Steps to reproduce:
* Enable both ccache and distcc in BUILDENV in /etc/makepkg.conf.
* makepkg any package that invokes the compiler in package(), for example ncurses.
* Observe the error during the "make install" command.
FS#66828 - strcpy with realloc Expand Collapse
Summary and Info:

Pacman source code:

file src/pacman/util.c line 1241 and 1242:

optstring = realloc(optstring, strlen(optstring) + strlen(status) + 1);
strcpy(optstring + strlen(optstring), status);

No realloc error checking.

Also, using strcpy in pacman/libalpm is not very good sign.


Steps to Reproduce:

None yet but should "work" in low memory conditions.

FS#67811 - [meta-bug] downloader issues Expand Collapse
This is to serve as a tracker for issues or improvements to be made to the parallel downloader before the 6.0 release.



 FS#66472  - Delete .sig in addtion to package when failing to validate
FS#67812 - Capture and summarize downloader errors
FS#67813 - Improve downloader output when retrieving only signature files
FS#67850 - Broken output and file when downloading multiple files with the same name
FS#67973 - CTRL+C during parallel downloads mixes output and interrupt message
FS#68202 - TotalDownload does nothing
FS#68355 - pacman -Syup needs a newline after databse downloads

Text Version