Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#64061 - [libldap] Dependency on e2fsprogs?

Attached to Project: Arch Linux
Opened by Steve M (smmalis37) - Tuesday, 08 October 2019, 02:48 GMT
Last edited by Antonio Rojas (arojas) - Saturday, 19 October 2019, 08:28 GMT
Task Type General Gripe
Category Packages: Core
Status Assigned
Assigned To Jan de Groot (JGC)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


I'm curious as to why a library for a network protocol has a dependency on file-system level utilities. This feels odd to me, as I wouldn't expect plain protocol support to require a specific filesystem. Can this dependency be removed? If not, should there be a dependency on similar utilities for other filesystems?
This task depends upon

Comment by Steve M (smmalis37) - Tuesday, 08 October 2019, 03:02 GMT Comment by Doug Newgard (Scimmia) - Tuesday, 08 October 2019, 03:03 GMT
Your other ticket has nothing to do with this one at all.
Comment by Eli Schwartz (eschwartz) - Tuesday, 08 October 2019, 03:05 GMT
I'm unsure myself why it is needed, but it's been that way since 2011 (version 2.4.26-1).

Note that krb5 depends on e2fsprogs for a very good reason (or arguably a very bad reason) -- and it also depends on libldap -- so this may have been related to why it originally got added.

The reason krb5 depends on e2fsprogs is because it requires the shared library, which considers itself to be the "Common error description library". Yes, it is bizarre.

For extra humor value, btrfs-progs and reiserfsprogs both require e2fsprogs for the same reason. Have fun with that. ;)

... But yes, this does not seem to be the case for libldap specifically.
Comment by Steve M (smmalis37) - Tuesday, 08 October 2019, 03:17 GMT
Interesting, thanks for the info! Should libcom_err be moved into its own package that e2fsprogs and all these other packages could depend on instead? Or is the benefit of that too small to matter?