Dependency detector "breaks" if 2 packages provide the same lib in different paths
git-bruh opened this issue ยท 9 comments
If there are 2 packages that provide the same library in different directories (like /usr/lib
, /usr/lib32
), KISS's dependency detector adds the wrong package to depends
.
Eg:
glibc
: /usr/lib/libresolv.so
lib32-glibc
: /usr/lib32/libresolv.so
Now if you have something that links to -lresolv
, KISS will add lib32-glibc
to depends
instead of glibc
because of the pattern used in grep
:
+ pkg_owner -l '/libresolv.so.2$' /var/db/kiss/installed/...
+ pkg_owner='/var/db/kiss/installed/glibc/manifest
/var/db/kiss/installed/lib32-glibc/manifest'
+ pkg_owner='/var/db/kiss/installed/glibc/manifest
/var/db/kiss/installed/lib32-glibc'
+ pkg_owner=lib32-glibc
+ set -f
+ '[' lib32-glibc ]
+ printf '%s\n' lib32-glibc
This kind of issue could be prevented if KISS grep
-ed for a pattern like lib/libresolv.so.2
but that won't be possible when readelf
is the dep detector, since it only shows Shared library: [lib.so]
instead of the path.
I can't think of a solution for this and neither do i expect kiss
to accomodate for such situations since the "official" KISS is non-multilib and there's not many other situations where such an issue would arise. Just creating this issue to see what other's think of as possible solutions to this (So that kiss
can be patched by anyone running in such an environment).
This can be fixed by using both readelf
and ldd
. I will write up a patch and send it to the mailing list.
The most obvious usecase here is multilib, which of course KISS doesn't target. There are nonmultilib uses cases though, yes? Like if you decided to install a flurry of trash to /proc
I imagine we would have a similar problem...
I personally consider this a bugfix. Even though multilib is the case for here, we shouldn't rely on non-fullpath dependency resolve.
pkg_owns
is in itself a problematic and insecure function too, which was put in to make up for the non-fullpath expansion of readelf. I will write a patch to fix that up if you merge my fix for this one.
I agree that it's a bug.
I'll do some testing, and it'll probably get pushed next I hear from you ๐๐ป
Thanks @cemkeylan, the patch seems to be working fine. But doesn't it defeat the point of $KISS_ELF
if ldd
is gonna be called anyways ?
The point of using readelf
is accurate dependency resolution. When you call ldd
it will output dependencies, but also their dependencies. readelf
only shows direct dependencies, and calling ldd
to get fullpath of them doesn't change the premise, and doesn't defeat the purpose.
readelf
was mostly implemented to have kiss
be a bit smarter about the dependencies it says packages have to prevent strange breakages - that readelf
doesn't output the entire path is problematic, and in our case for no technically good reason.
I have sent the benchmark to the mailing list.
:)