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

> 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.
>
>> It may have worked before because older teams required a libstdc++
>> version
>> which is available on CentOS 7.
>
> Correct.
>
>> The broken chrome packages are the reason why RPM allowed the new teams
>> version being installed.
>
> Again, they are not broken, they are suitable for the systems they were
> built for, which would be current Fedora systems (which happen to have a
> newer libstdc++).
>
>> But because the chrome package doesn't really
>> provide to the systems what it claims,
>
> You're confusing here.  I assume you mean the package that provides the
> libstdc++ dependency which happens to have chrome in it's name but is
> not actually chrome and does not come from google or chrome.
I don't know where the package comes from but it's a broken package and
has something with chrome in the name. This package is the reason why the
teams RPM can be installed and doesn't work. Without this broken package
the new teams package could NOT have been installed and break.

Simon

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 10:39 pm, Simon Matter wrote:
>> And I ask again, how else would you expect the package to satisfy the
>> dependency in chrome for the newer libstdc++?
And yet you still have not answered this question.
> 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.
It is not broken, it does exactly what it intends to do.  It needs to 
provide the dependency in order to allow chrome to be installed, and 
with the usage of the correct LD_LIBRARY_PATH it allows chrome to run on 
the system where otherwise it would not.

Yes, it violates the Fedora packaging guidelines, it's a good thing it's
not a Fedora package, then.  Also please note the very first sentence on 
the main page of the guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/

"The Packaging Guidelines are a collection of common issues and the 
severity that should be placed on them. While these guidelines should 
not be ignored, they should also not be blindly followed."

Sometimes you have to break some rules to get things to work.  In this 
particular case the results are worth it for a great many people.


Peter