Cascading library dependencies with different versions?

[Richard Shaw]

I had a hard time trying to describe what I'm talking about, perhaps
there's actually a term for it, but as I go through all the dependencies of
OpenEXR I wanted to know if this is a problem or not which I think is best
shown by example:

So part of the dependency chain for blender is:
Blender
---> OpenEXR
---> OpenVDB
       ---> OpenEXR

So is it OK for OpenVDB to link against OpenEXR 2.x (openexr2) while
Blender links with OpenEXR 3.x? Or does the whole dependency stack need to
be upgraded at one time?

Thanks,
Richard

[Neal Gompa]

On Wed, Jul 7, 2021 at 3:32 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  I had a hard time trying to describe what I'm talking about, perhaps there's
> actually a term for it, but as I go through all the dependencies of OpenEXR I wanted to
> know if this is a problem or not which I think is best shown by example:
>
>  So part of the dependency chain for blender is:
>  Blender
>  ---> OpenEXR
>  ---> OpenVDB
>         ---> OpenEXR
>
>  So is it OK for OpenVDB to link against OpenEXR 2.x (openexr2) while Blender links with
> OpenEXR 3.x? Or does the whole dependency stack need to be upgraded at one time?
>  
Generally, they need to be upgraded together because if they're all
operating in one process, you can have program code from OpenEXR 2 and
OpenEXR 3 colliding in the Blender process and causing things to go
haywire.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Richard Shaw]

On Wed, Jul 7, 2021 at 2:36 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Wed, Jul 7, 2021 at 3:32 PM Richard Shaw
> <hobbes1069(a)gmail.com&gt; wrote:
>  >
>  > I had a hard time trying to describe what I'm talking about, perhaps
>  there's actually a term for it, but as I go through all the dependencies of
>  OpenEXR I wanted to know if this is a problem or not which I think is best
>  shown by example:
>  >
>  > So part of the dependency chain for blender is:
>  > Blender
>  > ---> OpenEXR
>  > ---> OpenVDB
>  >        ---> OpenEXR
>  >
>  > So is it OK for OpenVDB to link against OpenEXR 2.x (openexr2) while
>  Blender links with OpenEXR 3.x? Or does the whole dependency stack need to
>  be upgraded at one time?
>  >
>
>  Generally, they need to be upgraded together because if they're all
>  operating in one process, you can have program code from OpenEXR 2 and
>  OpenEXR 3 colliding in the Blender process and causing things to go
>  haywire.
>  
That's what I was afraid of. I'm doing my best to make sure I notice
dependency chains like this but it's completely manual and could be error
prone. There seem to be a lot of kde 4 related dependencies, some of them
seem to build with OpenEXR 3.x but I think I'll keep the whole stack at 2.x
just to be safe.

Thanks,
Richard

[Jerry James]

On Wed, Jul 7, 2021 at 1:42 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  That's what I was afraid of. I'm doing my best to make sure I
> notice dependency chains like this but it's completely manual and could be error
> prone. There seem to be a lot of kde 4 related dependencies, some of them seem to build
> with OpenEXR 3.x but I think I'll keep the whole stack at 2.x just to be safe. 

It sounds like you could use a dependency visualizer.  I've been
working on one this year; see https://pagure.io/depict.  I haven't had
time to work on it recently, but I hope to get back to it in a week or
2 and make the first actual release.

One of the tricks of using this particular dependency visualizer is
that it runs the dependencies all the way down to the bottom, which
often results in so much black ink that you can't actually see what is
going on.  I generally start by picking out all of the non-library
packages and adding them to --exclude (I've got to figure out a way to
do that automatically).  Then I start picking out parts of the graph
that I don't care about and adding them to --stop or --exclude.
Here's a command line to get you started:

python3 -m depict --input=json examples/rpm.js --input=rpm
--exclude=alternatives:bash:boost-filesystem:boost-iostreams:boost-locale:boost-program-options:boost-regex:boost-thread:ca-certificates:cmake-filesystem:coreutils:cracklib-dicts:crypto-policies:dejavu-sans-fonts:dracut:filesystem:gawk:glib2:glibc:google-droid-sans-fonts:grep:grub2-common:grubby:gzip:hicolor-icon-theme:hwdata:iso-codes:kbd:langpacks-core-font-en:libgcc:libgfortran:libgomp:libssh-config:libstdc++:libtool-ltdl:libX11:libX11-xcb:mkpasswd:openssl-pkcs11:opensubdiv:os-prober:pam:potrace:publicsuffix-list-dafsa:python3:python3-numpy:python3-requests:python3-setuptools:qt-settings:rtkit:sed:setup:shadow-utils:shared-mime-info:systemd:tbb:util-linux:which:zlib
--stop=elfutils-libs:fontconfig:gstreamer1-plugins-base:jemalloc:krb5-libs:libglvnd:libSM:libspnav:libXext:libXfixes:libXi:libXrender:libXtst:libXxf86vm:mesa-libGL:nss:pipewire-jack-audio-connection-kit:python3-libs:qt5-qtbase-gui:readline:systemd-libs
blender --output=dot blender.dot

You can then transform the dot file into any format dot supports, e.g.:

dot -Tpdf blender.dot > blender.pdf

I've attached the PDF derived from the above 2 invocations to this
message.  Regards,
-- 
Jerry James
http://www.jamezone.org/