> On 16.07.21 12:39, Simon Matter wrote: >>> On 16/07/21 10:19 pm, Simon Matter wrote: >>>>> I think you missed from a different post where the package was >>>>> created >>>>> by a different 3rd-party, not google. So how else would you expect >>>>> the >>>>> 3rd-party package to satisfy the dependency? >>>> >>>> I didn't say the chrome packages came from google. But, the TO has >>>> some >>>> chrome RPM installed which "provides" the libstdc++ version required >>>> by >>>> teams, but doesn't really provide this libstdc++ version to the whole >>>> system. That's why the RPM is broken, it claims to provide a libstdc++ >>>> version which it doesn't really provide. >>> >>> And I ask again, how else would you expect the package to satisfy the >>> dependency in chrome for the newer libstdc++? The package was >>> explicitly created to allow chrome to run on an older system that >>> doesn't have the newer libstdc++, by rights it should work with other >>> programs that need a newer libstdc++ as well provided that they set >>> LD_LIBRARY_PATH appropriately. So it does, in fact, provide the stated >>> dependency for the entire system, you just have to tell programs that >>> need it where to find it. >> >> And that's where it breaks the rules! It "provides" something that it >> doesn't really provide. That's NOT allowed with RPM because it breaks >> other applications. It breaks the whole meaning of dependency tracking >> of >> the RPM system. That's why the mentioned chrome package has to be >> considered broken. >> > > $ LANG=C rpm -qp --provides > https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm > warning: > https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm: > Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY > google-chrome = 91.0.4472.164 > google-chrome-stable = 91.0.4472.164-1 > google-chrome-stable(x86-64) = 91.0.4472.164-1 > $ > Hi Leon, The problem package is not from google but seems to be 'chrome-deps-stable' from wherever it comes. It provides 'libstdc++.so.6(GLIBCXX_3.4.22)(64bit)' which it can NOT because it installs its libs in /opt/google/chrome/lib. This is all explained in https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/ and this is why the package 'chrome-deps-stable' has to be considered broken and actually breaks teams. >From the above text: --%<-------------------------------------- Examples Pidgin plugin package On a x86_64 machine, the pidgin-libnotify provides pidgin-libnotify.so()(64bit) which it shouldn’t as this library is not inside the paths searched by the system for libraries. It’s a private, not global, "provides" and as such must not be exposed globally by RPM. To filter this out, we could use: %global __provides_exclude_from ^%{_libdir}/purple-2/.*\\.so$ --%<-------------------------------------- The 'chrome-deps-stable' RPM should have used '%global __provides_exclude_from ...' to exclude /opt as those libraries are "private, not global, "provides" and as such must not be exposed globally by RPM". That's why teams fails here, Microsoft is NOT the culprit in this case :-) Regards, Simon