On 3/12/18 3:13 AM, Alexander Kanavin wrote:
> On 03/12/2018 11:12 AM, Zhang Xiao wrote:
>> Config file udev.pc conflicts between 32 and 64 bit packages.
>> Use update-alternatives to add base_libdir as suffix to avoid it.
>> -inherit autotools update-rc.d qemu pkgconfig distro_features_check
>> +inherit autotools update-rc.d qemu pkgconfig distro_features_check
>> update-alternatives
>> +
>> +MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
>> +
>> +ALTERNATIVE_${PN}-dev = "udev.pc"
>> +ALTERNATIVE_LINK_NAME[udev.pc] = "${datadir}/pkgconfig/udev.pc"
>> +ALTERNATIVE_TARGET[udev.pc] =
>> "${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}"
>> +
>> +PACKAGE_PREPROCESS_FUNCS += "eudev_alternative_rename"
>> +
>> +eudev_alternative_rename() {
>> + # rename udev.pc
>> + mv ${PKGD}${datadir}/pkgconfig/udev.pc
>> ${PKGD}${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}
>> +}
>
> I'm afraid, I have to say no to the entire patchset. It's abusing
> update-alternatives to do what it was never meant for, and effectively
> renders one of the -dev packages broken, just so that package manager
> can satisfy dependencies.
>
> Let's first take a look at why dnf wants to install two different -dev
> packages in the first place, and why these seven recipes need to be
> fixed in particular. My understanding is multilib feature should be used
> only for libraries, and not for supporting development files.
In this case, because the user specifically asked for BOTH 32-bit and 64-bit
development components to be installed onto the target for their application
development. (This isn't a theoretical problem, but a specific problem from one
of our customers.)
I had a chance to talk to RP a bit about this today at ELC. We agree we need a
generic mechanism to handle these types of problems.
For a '.pc' file, there really should be no reason (under normal circumstances)
for them to conflict. Since if they are are specific they don't belong in the
datadir, but belong in the libdir.
For non-.pc files, if they are 'pkgconfig like', they should be converted to
package config (for the most part this seems to have happened, with a few things
'missed'.)
The remainder then are things that can't be converted for some reason. So the
'config', or helper or whatever files really need to 'match' the installed
binary.
There is no way to predict ahead of time which binary is going to be installed
-- so we really need some type of automated processing that can be used to say:
1) This is a known multilib issue.
2) This file is related to this other file, and should be installed to match.
Under the hood if it uses update-alternatives or anything else doesn't matter --
but in the recipe it should not explicitly require the rename, the ALTERNATIVE
and related declarations etc...
Perhaps something like:
MULTILIB_CONFLICT = "${bindir}/python3.5m-config:${bindir}/python3.5m"
The under the hood it can rename the 'python3.5m-config' to a nonconflicting
name (based on the base_libdir, since we know that will be unique)... and then
invoke a post-install script that will define an appropriate priority to ensure
that python3.5m-config will match the final 'python3.5m' version. (Possibly
using update-alternatives to manage this.)
--Mark
> Alex
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
