[OE-core] [PATCH v2 0/3] Debian multilib packaging fixes

Matt Madison matt at madison.systems
Tue Jan 5 17:00:40 UTC 2016


On Mon, Jan 4, 2016 at 12:56 PM, Aníbal Limón
<anibal.limon at linux.intel.com> wrote:
> Hi Matt,
>
> Sorry for the delay in the response, i'll test again your patches with
> the new one and the same error appears when build
> core-image-full-cmdline or core-image-sato.

No problem, I figured things would be slow around the holidays.

I think the problem with this specific configuration has to do with
trying to add lib32-connman to an image build that already had a
dependency on connman (from packagegroup-core-x11-sato-base, for
example).  I modified the DpkgPM class in package-manager.py to run an
'apt-get -f install' to fix the dependencies that APT thinks are
broken if the initial installation attempt fails.  That appears to
work around the issue adequately, and I see APT reporting

   ignore old unsatisfied important dependency on connman-conf:amd64

which is there because it cannot install both connman-conf and
lib32-connman-conf, since PACKAGE_ARCH is ${MACHINE_ARCH} in the
connman-conf recipe.

For my particular application, I didn't have any conflicts between
32-bit and 64-bit packages, so the patches I submitted were enough.

I'm not sure what the right answer for this should be; hacking in the
additional 'apt-get -f install' works around the problem here, but I'm
not sure it solves the general problem correctly.   APT implements the
Debian policy, and it's complicated - to do it "right" , we'd have to
ensure that all of the packages get tagged with the right combination
of Architecture and Multi-Arch headers, and I think we'd have to
change how we write dependencies in the control files to use the
'<pkg>:any' notation when that's appropriate.  I'm not even sure if
that could be computed automatically; it could require a significant
amount of manual review.

Thanks,
-Matt

>
>         MACHINE ??= "qemux86-64"
>
>         IMAGE_INSTALL_append = " lib32-connman"
>         require conf/multilib.conf
>         MULTILIBS = "multilib:lib32"
>         DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
>
>
> I'm reviewing if this an error in the meta data (because
> core-image-minimal builds) or in the class.
>
> Best regards,
>         alimon
>
> On 12/18/2015 08:34 AM, Matt Madison wrote:
>> This adds a third patch that fixes the problem where APT couldn't
>> resolve dependencies between when two packages of different architectures
>> both depended on an allarch package.
>>
>> Matt Madison (3):
>>   package_deb.bbclass, cross-canadian.bbclass: DPKG_ARCH mapping
>>     function
>>   package_manager.py: fixes for multilib deb packaging builds
>>   package_deb.bbclass: add 'Multi-Arch: foreign' tag to allarch packages
>>
>>  meta/classes/cross-canadian.bbclass |  2 +-
>>  meta/classes/package_deb.bbclass    | 37 +++++++++++++++++++++++++++----------
>>  meta/lib/oe/package_manager.py      | 17 +++++++++++------
>>  3 files changed, 39 insertions(+), 17 deletions(-)
>>



More information about the Openembedded-core mailing list