Hi Alan,
Build 156 is when I attempted to get pkgdepend to correctly handle
symlinks, so it seems likely to be the culprit for changing the
behavior. The resolve_links code seems to depend on eventually finding a
real file at the end of the chains to function properly. What I can't
remember right now is why I wrote the code like that. I think the reason
is that because an elf file can have multiple run paths, without a real
file to ground our choice on, we don't have a way to know which run path
is actually fulfilling the dependency.
The information that pkgdepend has is that /lib/libGL.so.1 doesn't
exist, and /usr/lib/libGL.so.1 ends in a dangling symlink. I can see an
argument that in that situation, perhaps pkgdep should choose the
dangling symlink. Suppose that /lib/libGL.so.1 does exist, should
pkgdepend now choose /lib/libGL.so.1 over the dangling symlink? I think
we could probably create a situation where real files (or symlink chains
which resolve to real files) are preferred over dangling symlink chains
which are preferred over non-existent files.
I would tend to say, though, that pkgdepend is actually doing the right
thing now and that its previous behavior, while accidentally correct for
the X gate, was wrong since pkgdepend had no way of knowing that there
would be an actual file to fulfill the dependency on libGL.so.1.
What I could see as a potential RFE would be a new type of file action
which claimed a spot on the file system, but didn't actually deliver
content. It would be used in a case like this where the packager knows
that a service will create a file in a certain location, but that file
isn't packaged.
Sorry I can't be of more help, but I think the right answer may very
well be that these need to be manually tagged dependencies.
Brock
On 02/15/11 04:42 PM, Alan Coopersmith wrote:
I know that our symlinks in the X packages to the (non-packaged/SMF created)
/var/run/GL paths is just asking for all kinds of fun, but they used to work.
We recently got a pair of matching bug reports though:
7015365 x11/server/xephyr package has missing dependency
7015340 x11/diagnostic/x11-info-clients package has missing dependency
Both of these contain binaries linked against the symlinked libraries:
From elfdump -d proto/root_i386/usr/bin/xdriinfo:
[3] NEEDED 0x1d5 libGL.so.1
[7] RUNPATH 0x1e0 /usr/lib
From elfdump -d elfdump -d proto/root_i386/usr/bin/amd64/Xephyr:
[33] NEEDED 0x20311 libGL.so.1
[45] RUNPATH 0x20328
/usr/lib/xorg/amd64:/usr/lib/amd64
The pkgdepend generate output still shows the dependency:
depend fmri=__TBD pkg.debug.depend.file=libGL.so.1 pkg.debug.depend.path=lib
pkg.debug.depend.path=usr/lib pkg.debug.depend.reason=usr/bin/xdriinfo
pkg.debug.depend.type=elf type=require
During resolution, it should be able to find the link in the manifest for
service-opengl-ogl-select which is part of the set being resolved (the X
pkgdepend steps are copied from ON's usr/src/pkg/Makefile):
link path=usr/lib/libGL.so.1 target=GL/libGL.so.1
link path=usr/lib/GL/libGL.so.1 target=../../../var/run/opengl/lib/libGL.so.1
But after resolution, it no longer lists a dependency on the
pkg:/service/opengl/ogl-select that delivers the /usr/lib/libGL.so.1 ->
/var/run/opengl/libGL.so.1 links (which in turn are linked to the correct
backend by the SMF service in that package at runtime).
The dependency was included up through our build 157 delivery, but disappeared
in 158, which would have been build with ipkg from build 156. I can't see
anything in the few changesets we integrated in build 158 that would have broken
it - is there a change to pkgdepend that would explain this? Do I just need to
manually include this dependency in our packages?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
