CentOS - Jul 2021 - Microsoft Teams on CentOS 7. Does the latest version work?

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
$


--
Leon

> 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