FS#63485 - [mate-control-center] mate-appearance-properties requires .so not provided by marco
Attached to Project:
Community Packages
Opened by Prism Tutaj (Prism019) - Saturday, 17 August 2019, 03:53 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 26 August 2019, 18:49 GMT
Opened by Prism Tutaj (Prism019) - Saturday, 17 August 2019, 03:53 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 26 August 2019, 18:49 GMT
|
Details
Description:
mate-appearance-properties links to libmarco-private.so.1 but marco provides libmarco-private.so.2 I am unable to change my background due to this. Additional info: marco version 1.22.2-1 mate-control-center version 1.22.1-1 Steps to reproduce: Run mate-appearance-properties |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Monday, 26 August 2019, 18:49 GMT
Reason for closing: Fixed
Additional comments about closing: I just moved mate-control-center 1.22.1-2 from [community-testing] to [community]
Monday, 26 August 2019, 18:49 GMT
Reason for closing: Fixed
Additional comments about closing: I just moved mate-control-center 1.22.1-2 from [community-testing] to [community]
If it "worked" even as a "workaround", then people wouldn't bother with versions, because it "works". But you're literally asking for corruption, incompatible symbols, and undefined behavior. Data loss is just as likely as crashes. And the whole point of undefined behavior is it is unpredictable.
Don't do it. Don't suggest other people do it.
I did not comment because I was looking for an argument with you. I commented because I was laying down the law.
Thou Shalt Not Advise Others To Break Their System.
Flyspray does not add "tags" to user accounts. :) You may, however, click on a username to see which Flyspray group a given user is attached to.
Anyway, official Arch policy on faking the soname of a library remains https://wiki.archlinux.org/index.php/Frequently_asked_questions#If_I_need_an_older_version_of_an_installed_library,_can_I_just_symlink_to_the_newer_version?
We strongly discourage it in the general way of things, and tend to really dislike the idea of such hacks being suggested for broad consumption. There is *always* a better way.
And none of that is going to get the package fixed. Changes to the package will get the package fixed. Constructive discussion about fixing the package, is welcomed... discussion about modifying your own system to still execute the program is less welcomed, as it doesn't actually solve the bug, but it is also not against the rules. Advising people to use workarounds widely regarded as an antipattern starts veering into territory that *is* against the rules, and mixed in with insults means I'm likely to just start deleting comments. :(
Hopefully the package maintainer will respond soon. In the meantime, you can try downloading the PKGBUILD for mate-control-center, bumping the pkgrel to 1.1, and rebuilding it to see if that works. It likely will, although I see upstream has released a new mate-control-center 1.23.2 version as well.
it's a complete shame that a package of this importance takes this long to fix.
Then once mate-control-center gets fixed I can just upgrade both to the latest version have have no issues, right? Since I'm not messing around with any libraries.
There's an upstream 1.23.2 release but that's the odd-numbered development series; the "normal" mate-control-center is still at 1.22.1 .
I have to say it is a bit surprising to have soname bumps in a semver patchlevel release...
I had already tried this locally by modifying the PKGBUILD.
Main problem is that when I update my system still asks to update to 1.22.2. And that's what breaks mate-control-center (partially... as far as I noticied only appearence doesn't work)
Main problem is still that maintainer updated the Marco to a newer no a newer version (1.22.2) not only the soname (i think... sorry if im saying something stupid , still learning here!) and didn't notice that the remaining packages and depedencies are all on 1.22.1, still.
Previous version and your version on testing :
libmarco-private.so -> libmarco-private.so.1.0.0
libmarco-private.so.1 -> libmarco-private.so.1.0.0
libmarco-private.so.1.0.0
Version updated on 15-08-2019 by maintainer
libmarco-private.so -> libmarco-private.so.2.0.0
libmarco-private.so.2 -> libmarco-private.so.2.0.0
libmarco-private.so.2.0.0
This is what breaks mate-control center.
That plus 3 confirmations seems good enough to me. :)
@bassopt,
For what it's worth, the difference between 1.22.1 and 1.22.2 is supposed to be "a bug fix specific to marco which can be updated on its own", so things like this should not break. I do not maintain mate-desktop, but I do maintain cinnamon, which is developed in a similar manner. Such bugfix releases are fairly common, and different desktop components don't need to match exact versions (one might have an update while others do not).
The issue is, apparently, simply because marco updated its ABI and soname in a bugfix release. My contact did say he didn't like it, but wasn't around to argue against it at the time...
It's unfortunate that that happened at all, and regrettable that we didn't catch it.
@cesura,
I find it helpful to run the `checkpkg` tool every time before I release a package, and if the package reports *any* changed filenames, I try to figure out if that would affect any other packages.
It would in this case have reported:
$ checkpkg
usr/lib/libmarco-private.so.1 | usr/lib/libmarco-private.so.2
usr/lib/libmarco-private.so.1.0.0 | usr/lib/libmarco-private.so.2.0.0
==> Sonames differ in marco!
libmarco-private.so=1-64 | libmarco-private.so=2-64
(plus a new locale, which doesn't matter)
That soname is suspicious in a patchlevel release and should anyway be double-checked for compatibility with other packages (sogrep -v community libmarco-private) in the hope of avoiding mistakes.