Pacman

Roadmap for version 5.1.2 Expand all | Collapse all

83% of 6 tasks completed. 6 open tasks:

FS#50875 - pacman removes twice the same conflicting/to-be-replaced package Expand Collapse
This report is about AUR packages hosted in unofficial user repos.

There's dbus-openrc-1.10.10-5 installed, which on -Syu is to be replaced by dbus-openrc-20160917-2. The latter replaces/conflicts with the former and depends on dbus-nosystemd (1.10.10-4). For the sake of clarity, dbus-openrc-1.10.10 is both dbus-nosystemd + dbus-openrc initscript.

Pacman asks whether to replace dbus-openrc with openrc-eudev/dbus-openrc and informs of the following:

:: Replace dbus-openrc with openrc-eudev/dbus-openrc? [Y/n]
resolving dependencies...
looking for conflicting packages...

Packages (3) dbus-nosystemd-1.10.10-4 dbus-openrc-20160917-2 dbus-openrc-1.10.10-5 [removal]

:: Processing package changes...
(1/1) removing dbus-openrc [---------] 100%
(1/2) installing dbus-nosystemd [---------] 100%
error: could not remove database entry dbus-openrc-1.10.10-5
error: could not remove entry 'dbus-openrc' from cache
(2/2) upgrading dbus-openrc [---------] 100%

Running pacman with --debug, I see:

1. dbus-openrc-1.10.10-5 being removed
2. dbus-nosystemd being installed
3. dbus-openrc-20160917 being upgraded, but only after dbus-openrc-1.10.10-5 is removed again (debug: removing old package first)

Step 3 removes all dbus-nosystemd's files common to dbus-openrc-1.10.10. However, if I upgrade with just 'pacman -S dbus-openrc', the operation completes successfully because the installation order is changed and dbus-nosystemd is installed second, after the old dbus-openrc is removed. Please, see the attached debug log (a shorter version for easier reading also included).

I know this is a rare case (and in unofficial repos at that), but shouldn't pacman keep a record of removed packages until the upgrade operation is finished and not remove the same package again later?
FS#55534 - Replaced package retained and upgraded as dep causes errors Expand Collapse
I ran into a problem with replaces after splitting flatpak-builder from flatpak:

- flatpak 0.9.8-1 is installed.
- flatpak 0.9.10-2 and flatpak-builder 0.9.9-1 are available.
- flatpak-builder has replaces=('flatpak<0.9.10') and depends=(flatpak)

If the user confirms the replace, pacman will first remove flatpak and later upgrade it, throwing two errors:

error: could not remove database entry flatpak-0.9.8-1
error: could not remove entry 'flatpak' from cache

The upgrade seems to work fine except for the noise. Perhaps this would cause more problems if flatpak had more complex pre/post scripts, as this bug probably triggers unwanted runs of the install and remove functions.
FS#56756 - Resetting signal handlers prior to calling hooks Expand Collapse
Summary and Info:

I'm quoting Andrew Gregory from  FS#49816 :

- Hooks are run with SIGPIPE ignored which causes '... | grep -q ...' in the dkms script to print the error when the grep exits early and the echo receives EPIPE.
- does not ignore SIGPIPE, GPGME does. I need to look into resetting signal handlers prior to calling the hook.
- libalpm uses GPGME for signature checking. GPGME uses pipes to communicate with external processes. When GPGME is initialized it sets SIGPIPE to be ignored, so that it can gracefully handle EPIPE rather than have the entire application die.

This bug is to track fix into pacman, and when I can remove the workaround in dkms.

FS#60347 - [libalpm] Can’t get check & make dependencies of a package Expand Collapse
Summary and Info:
alpm_pkg_get_{check,make}depends(alpm_pkg_t*) functions in lib/libalpm/alpm.h are supposed to return check & make dependencies for a given package, but don’t (both systematically return an empty linked list).
Patching lib/libalpm/be_sync.c by copying the behavior for depends & optdepends does the job.

You’ll find attached the git diff of the change in question.
FS#60396 - [pacman] resizing terminal window causes hook output to stop and Expand Collapse
Description:
alpm hooks that are executing when the terminal is resized (vertically or horizontally) will no longer output to stdout and will conclude with "error: command failed to execute correctly"

Additional info:
* package version(s): core/pacman 5.1.1-1

Steps to reproduce:
1. Open a terminal and start an update that will fire a "long-running" hook (e.g. mkinitcpio will take a few seconds at least)
2. While the hook (e.g. mkinicpio is generating the initramfs) resize the terminal
3. stdout for the hook will stop and eventually report that the command failed to execute correctly

I was able to reproduce this on i3+termite and gnome(wayland)+gnome-shell on 2 different machines. The attached log is what I see for the execution of the mkinitcpio hook in my example, the rest of the update/install/other hooks/etc. appear to continue fine (unless I resize during another hook then that hook will fail, I had a test hook that also just ran for 2-3 seconds after mkinitcpio to confirm)
FS#60681 - makepkg breaks if arch happens to be set in the callers environm Expand Collapse
Summary and Info:


Steps to Reproduce:

$ export arch=linux-x86
$ git clone https://aur.archlinux.org/package-query.git
$ cd package-query && makepkg -s
==> ERROR: arch should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: conflicts_linux-x86_64: not found
==> ERROR: conflicts_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: depends_linux-x86_64: not found
==> ERROR: depends_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: makedepends_linux-x86_64: not found
==> ERROR: makedepends_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: md5sums_linux-x86_64: not found
==> ERROR: md5sums_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: optdepends_linux-x86_64: not found
==> ERROR: optdepends_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: provides_linux-x86_64: not found
==> ERROR: provides_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: replaces_linux-x86_64: not found
==> ERROR: replaces_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: sha1sums_linux-x86_64: not found
==> ERROR: sha1sums_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: sha224sums_linux-x86_64: not found
==> ERROR: sha224sums_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: sha256sums_linux-x86_64: not found
==> ERROR: sha256sums_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: sha384sums_linux-x86_64: not found
==> ERROR: sha384sums_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: sha512sums_linux-x86_64: not found
==> ERROR: sha512sums_linux-x86_64 should be an array
/usr/share/makepkg/util/util.sh: line 45: declare: source_linux-x86_64: not found
==> ERROR: source_linux-x86_64 should be an array

$ unset arch
$ makepkg -s /* all OK */



Roadmap for version 5.2.0 Expand all | Collapse all

100% of 1 tasks completed. 1 open tasks:

FS#60880 - [pacman] throws ambiguous error without gnupg support and having Expand Collapse
Summary and Info:

When pacman is compiled without gnupg support, then specifying SigLevel in server section causes pacman to throw
ambiguous error:

error: could not register 'core' database (wrong or NULL argument passed)

This does not provide anything useful into logs either, so without any knowledge one has to dig in pacman
codebase to figure out the cause of this error.

Ideally, SigLevel should be ignored when pacman hasn't been compiled with gnupg support

Steps to Reproduce:

Configure pacman without gnupg (not being present compile time - that's my case; or using appropriate ./configure flag)
Try to add a server section into pacman.conf with SigLevel, like:

[core]
Server = https://foo.bar/baz/$repo/os/$arch
SigLevel = Never

Get this error message:

error: could not register 'core' database (wrong or NULL argument passed)

Roadmap for version 6.0.0 Expand all | Collapse all

22% of 36 tasks completed. 27 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#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#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#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#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#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#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.

Text Version