At the moment the libsecret package does not offer ABI_X86 flags and only installs a single version of the library that is native to the architecture. This blocks installation of skypeforlinux, which is only available with an x86_64 ABI. Please add support for multilib compatibility to the libsecret package.
I tried to make this ebuild multilib myself, and it worked to simply add multilib-minimal, copy source, add multilib dependencies and change functions to multilib_*. However, gobject-introspection is not multilib either (bug #642094), so I had to set USE=-introspection. It also has a runtime dependency on gnome-keyring, which is likewise not multilib yet (bug #615154). Adding a depends on it for now.
I highly doubt that multilib gnome-keyring dep would be strictly needed here. gnome-keyring just provides a service that is autostart, and some plugins for that. libsecret doesn't actually link to gnome-keyring as far as I can see, thus it just needs the running service, which will be native 64bit (can't have two of those running, claiming the same DBus interfaces...). The use case described in #615154 however does need it, to get some pkcs#11 plugin working for 32bit consumer. I don't think this is the requirement here for libsecret. Of course it'd be nice to have it for that purpose, but I don't think you need it for libsecret multilibbing.
On gobject-introspection: I thought it would not be needed as multilib, and yet, if I try to merge a multilib libsecret, it fails at configure time because it cannot find gobject-introspection. So there is some issue with it, maybe there's a way to solve it without making a multilib package. One workaround would be to disable the introspection USE flag in libsecret when not on native ABI, of course, but that doesn't sound like a true fix. And yes, gnome-keyring is a runtime dependency and libsecret is valid if it's not present. ksecrets could have been an alternative to it too. But it's technically in RDEPENDS. Maybe saying that it's blocking is a bit strong, more that the two issues are related to one another.
$(multilib_native_use_enable introspection) and $(multilib_native_use_enable vala)
One thing I don't understand is why libsecret would need multilib support or why skype ebuild would be multilib enabled at all since the available binaries are amd64 only, for rpms and debs.
That's the whole reason why: if you're not on amd64, you need to be running multilib to run Skype, and pull in all its amd64 dependencies.
(In reply to Gilles Dartiguelongue from comment #5) > One thing I don't understand is why libsecret would need multilib support or > why skype ebuild would be multilib enabled at all since the available > binaries are amd64 only, for rpms and debs. x32
And this is causing tangible breakage: https://qa-reports.gentoo.org/output/gentoo-ci/cf3ef1fe0/output.html#net-im/skypeforlinux
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5fd71edd6526b6072030d0465a639ce5fd7bf80f commit 5fd71edd6526b6072030d0465a639ce5fd7bf80f Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-05-11 15:37:35 +0000 Commit: Gilles Dartiguelongue <eva@gentoo.org> CommitDate: 2018-05-17 10:04:59 +0000 app-crypt/libsecret: Enable multilib support LIBGCRYPT_CONFIG is needed because macro uses AC_PATH_PROG instead of AC_CHECK_TOOL. See libgcrypt issue at https://dev.gnupg.org/T3982. Closes: https://bugs.gentoo.org/642054 app-crypt/libsecret/libsecret-0.18.6-r1.ebuild | 88 ++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
