[opensuse-factory] libLLVM# stays when libLLVM#+1 is added
# rpm -qa | grep LLVM libLLVM8-8.0.1-5.1.x86_64 libLLVM9-9.0.0-3.1.x86_64 # inxi -S System: Host: gb250 Kernel: 5.2.14-1-default x86_64 bits: 64 Console: tty 3 Distro: openSUSE Tumbleweed 20191109 This seems to be a regular happening whenever a major libLLVM version change occurs, happened 5>6, 6>7, 7>8 IIRC. Shouldn't the old be removed by the zypper dup that provides the new? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 11, 2019 at 08:34:32AM -0500, Felix Miata wrote:
# rpm -qa | grep LLVM libLLVM8-8.0.1-5.1.x86_64 libLLVM9-9.0.0-3.1.x86_64 # inxi -S System: Host: gb250 Kernel: 5.2.14-1-default x86_64 bits: 64 Console: tty 3 Distro: openSUSE Tumbleweed 20191109
This seems to be a regular happening whenever a major libLLVM version change occurs, happened 5>6, 6>7, 7>8 IIRC. Shouldn't the old be removed by the zypper dup that provides the new?
Not really. There are usually packages that depend on several versions of libllvm. It should be removed eventully and is not, though. Same with libav* Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 11. November 2019 14:35:02 schrieb Felix Miata
# rpm -qa | grep LLVM libLLVM8-8.0.1-5.1.x86_64 libLLVM9-9.0.0-3.1.x86_64 # inxi -S System: Host: gb250 Kernel: 5.2.14-1-default x86_64 bits: 64 Console: tty 3 Distro: openSUSE Tumbleweed 20191109
This seems to be a regular happening whenever a major libLLVM version change occurs, happened 5>6, 6>7, 7>8 IIRC. Shouldn't the old be removed by the zypper dup that provides the new?
No, this only happens if llvm8 is no longer in the repository AND it can be removed from your system without breaking other things. At this moment, we have llvm 6 - 9 all in place (some could hopefully be cleaned up) Cheers, Dominique
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 11.11.19 um 14:34 schrieb Felix Miata:
This seems to be a regular happening whenever a major libLLVM version change occurs, happened 5>6, 6>7, 7>8 IIRC. Shouldn't the old be removed by the zypper dup that provides the new?
There are three issues here: * Packages that build against the unversioned metapackages llvm-devel, clang-devel etc. start linking with the new version only when they are rebuilt. The version update of the metapackage itself doesn't trigger a rebuild, probably because it doesn't contain actual libraries. That's currently not the case though, all packages have been rebuilt. * Some packages need older versions of libLLVM. One example is the Glasgow Haskell compiler ghc, which is still using llvm6. Then there are ldc, a D compiler, and beignet, an OpenCL implementation, that use llvm7. Currently there seems to be no package using llvm8, but I can't remove it before llvm6 & llvm7. (Because one of these mentioned packages might update to llvm8.) You can see the build dependencies of llvm versions with osc whatdependson openSUSE:Factory llvm<n> standard x86_64 and runtime dependencies of libLLVM.so with zypper search --requires 'libLLVM.so.<n>()(64bit)' That doesn't show ghc-compiler though, which needs the llvm executables. (Probably llc.) * I think zypper is conservative about removing libraries. You need at least "solver.cleandepsOnRemove = true" in /etc/zyp/zypp.conf. I'm not sure whether that's enough though. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Nov 12 2019, Aaron Puchert wrote:
* Packages that build against the unversioned metapackages llvm-devel, clang-devel etc. start linking with the new version only when they are rebuilt. The version update of the metapackage itself doesn't trigger a rebuild, probably because it doesn't contain actual libraries.
But the binary package then depends on the versioned library, and once that version disappears the Factory rebuild script will automatically trigger rebuild of those packages that depend on the missing llvm library. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2019-11-12 at 10:17 +0100, Andreas Schwab wrote:
On Nov 12 2019, Aaron Puchert wrote:
* Packages that build against the unversioned metapackages llvm-devel, clang-devel etc. start linking with the new version only when they are rebuilt. The version update of the metapackage itself doesn't trigger a rebuild, probably because it doesn't contain actual libraries.
But the binary package then depends on the versioned library, and once that version disappears the Factory rebuild script will automatically trigger rebuild of those packages that depend on the missing llvm library.
Just that llvm8 is still in the distro and thus the library will never be missing. For llvm, though, I triggered a rebuild of everything dependnig on it - that's how the move to llvm9 happened And, again: since the library still exists in the repo, it is not marked as weakremover and thus is never automatically removed from user systems. Cheers, Dominique
participants (6)
-
Aaron Puchert -
Andreas Schwab -
Dominique Leuenberger -
Dominique Leuenberger / DimStar
-
Felix Miata -
Michal Suchánek