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
--
-Alan Coopersmith- [email protected]
Oracle Solaris Platform Engineering: X Window System
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
