How to deal with multiple versions of LLVM

B

bakul

I have llvm19, llvm20 & llvm21 installed as various other packages depend on them. Is there a way to remove two of three *without* having to rebuild packages locally but somehow fixing up their dependencies?

I am guessing no, as they likely depend on some shared library provided by each of these large large vile mammoth packages but I thought I'd ask. I guess I can try to replace them with the -lite versions, right?
 
SirDice said:
Does pkg autoremove remove them
Click to expand...
No. I install packages (except drm-*) so build dependencies shouldn’t matter. You need version dependent shared libs at runtime. I suppose I can force install pkgs dependent on older llvms but in the hope pkg builder machines are updated but I doubt it.
 
bakul said:
I install packages (except drm-*) so build dependencies shouldn’t matter
Click to expand...
Then you won't have build dependencies installed. Except for the things needed to build the DRM drivers.

bakul said:
You need shared libs at runtime.
Click to expand...
Not always, for example, there are 185 ports having a build dependency on LLVM19 but only 85 have it as a library dependency.

bakul said:
I suppose I can replacing pkgs dependent on older llvms but in the hope pkg builder machines are updated but I doubt it.
Click to expand...
It can get a bit annoying indeed. Things get even worse if GCC is thrown into the mix too. You can end up with several different compilers and versions installed. It's unfortunate there's so much variation. Won't be easy to fix, especially if you rely on packages. If you build from ports (or build your own repository) you have a lot more flexibility.
 
SirDice said:
Won't be easy to fix, especially if you rely on packages. If you build from ports (or build your own repository) you have a lot more flexibility.
Click to expand...
Looks like none of my packages depend on llvm{20,21} after doing an autoremove but autoremove doesn't remove llvm{20,21} so I manually deleted them. I want to avoid port builds as it is just a waste of time, energy and some diskspace (for me)! And more hassles. So have to live with the tradeoffs I made! Thanks for you help.

Now and then I think of a graphical program to show all the dependencies (with diff. colored arcs from a selected pkg/port for dependent pkgs and packages it depends on, with zoom in/out, search, more advanced pkg related functions etc.). See https://sigmajs.org/ for a visualization example. But this is a pretty nontrivial project so I go back to my inertial state!
 
bakul said:
I manually deleted them
Click to expand...
That will be fine too. If a pkg-delete(8) only deletes those two then nothing is actually depending on them. If you delete something and some other package has a dependency on it it would also get deleted.

You can also check beforehand; pkg info -r <packagename>, it will show a list of packages that are depending on it. If nothing shows up you can safely remove it.

Code: 
     -r, --required-by
             Display the list of packages which require pkg-name.
pkg-info(8)
 
Erichans said:
Perhaps something like ports-mgmt/portgraph; mentioned in How can I visually view a ports dependencies?
There's also ports-mgmt/pkg-graph; no experience with that.
Click to expand...
Thanks. graphics/graphviz will do a good job for sure. When a graph is very large (37.5K+ nodes for ports), it will look like a large dust cloud so you need to be able to zoom in/out, map attributes to colors, size (based on fan-in, fan-out), hide/colorize arcs and nodes, associate actions with nodes etc. So for me interactivity is the more interesting part (& much harder)!
 
You must log in or register to reply here.
Back
Top