I don't have any objection to doing a pkgmogrify that way, as long as
you know you're building on quicksand. The idea of a manual override of
resolution is an interesting one. I'd have to think about how it might
compare in use to the "empty" file action (which wouldn't necessarily
have to be a file action either). I'd be curious whether you'd want to
set the manual override on each action which depended on libGL.so.1, or
whether you'd want to be able to say once, in service/opengl/ogl-select,
that it delivers libGL.so.1 in a non-traditional way.
The advantage I see with the "empty" file action is that then you'd also
get conflicting file errors if you were installing both ogl-select and
another package which actually delivered var/run/opengl/lib/libGL.so.1.
Brock
On 02/16/11 12:43 PM, Alan Coopersmith wrote:
Thanks - I suppose I should have always known that we were lucky that pkgdepend
was handling these for us.
Instead of adding manual depend actions and ignoring the pkgdepend errors, would
I be insane to do use pkgmogrify between the pkgdepend generate& resolve steps
to manually resolve the dependencies pkgdepend found for us?
This seems to work:
--- a/pkg/Makefile
+++ b/pkg/Makefile
@@ -309,7 +309,9 @@
$(PKGDEBUG)$(RM) $(@)
$(PKGDEBUG)if [[ ! -f $(@:%.dep=%.nodepend) ]]; then \
pkgdepend generate -m $(PKGDEP_TOKENS:%=-D %) $(<) \
- $(PKGROOT)> $(@); \
+ $(PKGROOT)> $(@).raw ; \
+ $(PKGMOGRIFY) $(PKGMOG_VERBOSE) $(PM_INC:%= -I %) \
+ -O $(@) $(@).raw gl-depends; \
else \
$(CP) $(<) $(@); \
fi
with this in gl-depends:
<transform depend pkg.debug.depend.file=libGL.so.1 -> \
edit fmri __TBD pkg:/service/opengl/ogl-select>
<transform depend pkg.debug.depend.file=libglx.so -> \
edit fmri __TBD pkg:/service/opengl/ogl-select>
I understand that I'm depending on private/unstable attributes of pkgdepend
there, and it would be nice to someday have a pkg.depend.* attribute I could
set instead to do manual resolution overrides, similar to Tim's proposed
pkg.depend.bypass-generate. This seems better than requiring my developers
(or those in Userland& JDS) to remember which packages need special handling
for libGL dependencies.
It also makes me completely "pkgdepend clean" today, with no issues reported
by pkgdepend resolve any longer.
-alan-
On 02/15/11 10:34 PM, Brock Pytlik wrote:
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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
