Created attachment 333232 [details]
After building sys-process/audit-2.2.2, it suggests the following:
* Old versions of installed libraries were detected on your system.
* In order to avoid breaking packages that depend on these old libs,
* the libraries are not being removed. You need to run revdep-rebuild
* in order to remove these old dependencies. If you do not have this
* helper program, simply emerge the 'gentoolkit' package.
* # revdep-rebuild --library '/lib/libauparse.so.0' && rm '/lib/libauparse.so.0'
However, the /lib/libauparse.so.0 symlink is *provided* by sys-process/audit-2.2.2
# equery f =sys-process/audit-2.2.2 | grep "^/lib"
Removing the symlink breaks audit's executables.
Did someone get a little excited when they were authoring this ebuild, or was libauparse.so.0* supposed to be bumped to libauparse.so.1* ?
This is also the issue on amd64 with _STABLE_ sys-process/audit-2.1.3-r1.
confirming for audit-2.2.2 on amd64
The bug is much worse:
It is not an audit.ebuild bug BUT a portage one:
The libauparse.so.0 is a link
/lib64/libauparse.so.0 points to real /lib64/libauparse.so.0.0
But this is not renewed with the new version! This actual gets to the situation
that the portage system thinks it holds the new audit-2.2.2 version
but the old version is living on!
I guess this has to do with portages new feature!
Please reasign this from audit to a portage issue !!!
My portage had been kept to stable too long:
This bug seems the same as
which is solved with newest sys-apps/portage-18.104.22.168
I will try ...
No, the new portage-22.214.171.124 doesn't work either
I confirm this, this is a bug in sys-process/audit-2.* ebuilds.
They contains these two lines:
# Preserve from the audit-1 series
Although libaudit.so major version was incremented by upstream
when going from audit-1.* to audit-2.* no such change was done to
So the preservation is unnecessary here (unless these two versions
aren't binary compatible, but then the major version of this
library would have to be changed).
revdep-rebuild --library '/lib/libauparse.so.0' && rm '/lib/libauparse.so.0' will lead to breakage until next revdep-rebuild is run which will force the rebuild hense esculation in importants.
Why don't drop all that magic now that we have preserved-rebuild enabled in current portage?
Created attachment 380506 [details, diff]
audit-2.2.2-r2.ebuild excluding libauparse from preserve_old_lib*
This patch excludes libauparse from that preserve_old_libs* call.
If that is all that is needed for stabilization of audit-2.2.2?
This issue is still present in the ebuild for version 2.4.1. The issue is still exactly the same, thus applying a patch like the one provided in comment #9 would still fix it. Anyone out there willing to fix this? Could _please_ somebody out there fix this?