xpra doesn't update on Centos 7

[Bob Tennent]

Latest updates fail because you've provided lz4-1.8.3-1.el7_6.x86_64
but no corresponding .i686 package. Either remove the former or provide the latter.

[Antoine Martin]

Why would you have the i686 version installed on an x86_64 system?
Please always include the full error message.
What depends on the specific version you have installed? Why does it care about the version for used by another arch?

There are no official i686 builds of centos7, only as an alt arch, so we won't be providing those builds.

FYI: this is winswitch's bug tracker, xpra's is here: ​https://xpra.org/trac/.

[Bob Tennent]

There are 137 i686 packages on my system, presumably because of i686-only applications and their dependencies. lz4-1.7.5-2.el7.i686 is needed by systemd-libs-219-62.el7.i686.

The full error message:

---> Running transaction check
---> Package lz4.x86_64 0:1.7.5-2.el7 will be updated
---> Package lz4.x86_64 0:1.8.3-1.el7_6 will be an update
--> Finished Dependency Resolution
Error:  Multilib version problems found. This often means that the root
       cause is something else and multilib version checking is just
       pointing out that there is a problem. Eg.:
       
         1. You have an upgrade for lz4 which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of lz4 of the
            different architecture. If you exclude the bad architecture
            yum will tell you what the root cause is (which package
            requires what). You can try redoing the upgrade with
            --exclude lz4.otherarch ... this should give you an error
            message showing the root cause of the problem.
       
         2. You have multiple architectures of lz4 installed, but
            yum can only see an upgrade for one of those architectures.
            If you don't want/need both architectures anymore then you
            can remove the one with the missing update and everything
            will work.
       
         3. You have duplicate versions of lz4 installed already.
            You can use "yum check" to get yum show these errors.
       
       ...you can also use --setopt=protected_multilib=false to remove
       this checking, however this is almost never the correct thing to
       do as something else is very likely to go wrong (often causing
       much more problems).
       
       Protected multilib versions: lz4-1.8.3-1.el7_6.x86_64 != lz4-1.7.5-2.el7.i686

This is after updating the other xpra packages using yum update -x lz4.

[Bob Tennent]

Why does xpra need to update lz4?

[Antoine Martin]

Why does xpra need to update lz4?

lz4 is not part of the default centos distribution and xpra does not require any external repositories to deploy.

I am closing this as 'wontfix' because we can't have it both ways and we are not going to start building i686 packages either.

[Bob Tennent]

z4 is not part of the default centos distribution

Nonsense: ​http://mirror.centos.org/centos/7/os/x86_64/Packages/lz4-1.7.5-2.el7.x86_64.rpm

[Antoine Martin]

Nonsense
​http://mirror.centos.org/centos/7/os/x86_64/Packages/lz4-1.7.5-2.el7.x86_64.rpm

You're right, it is now. But it wasn't when centos 7 was released. In fact, it seems to only have been added in centos 7.4

So I guess that starting with centos 7.4 we should stop building lz4, but continue to build python-lz4. (making things even more complicated for: ​http://xpra.org/trac/ticket/2040)

[Bob Tennent]

Again I ask, why does xpra need to update lz4? If you would provide 1.7.5,
updates of centos-7.4 and up would not be affected.

[Antoine Martin]

Again I ask, why does xpra need to update lz4?

As I tried to explain above, we started packaging lz4 before centos did.

[Bob Tennent]

But could you not now replace your 1.8.3 rpm by Centos's 1.7.5? I don't believe anyone would be adversely affected.

[Antoine Martin]

But could you not now replace your 1.8.3 rpm by Centos's 1.7.5? I don't believe anyone would be adversely affected.

I may also have to rebuild python-lz4 against that older lib - or at least check for compatibility issues with all the compression settings we use.
Testing installs as well as upgrade paths.
If a rebuild is required, then all those who have the newer lz4 version already installed would hit problems and I don't think we can easily force them to downgrade through the repository.

All of this takes time - which is in limited supply.