Mailinglist Archive: opensuse-packaging (114 mails)

< Previous Next >
Re: [opensuse-packaging] noarch (sub-)package with ELF files in it
  • From: Křištof Želechovski <giecrilj@xxxxxxxxxxxx>
  • Date: Sun, 01 Dec 2013 15:14:24 +0100
  • Message-id: <2090848.eIyLG2QVAx@ne-1-26>
Dnia sobota, 30 listopada 2013 21:44:56 Andrey Borzenkov pisze:

Currently all grub2 subpackages are arch-dependent. This already means
we have two absolutely identical packages - grub2-i386-pc for i386 and
x86_64 (grub2 run-time on legacy BIOS is always 32 bit). As long as this
was the only overlap this could be ignored. But now upstream added
native support for Xen PV guests (a.k.a. pvgrub2). grub2 core.img must
match guest architecture; which would mean that we'd need two
*identical* subpackages for each i386 and x86_64 and possibly for other
archs (ARM?)

So I'm looking at making those subpackages noarch. That would reduce
build time (could skip building some of them) and space (omitting
identical packages). In principle from pure RPM PoV it works without
problems. But our build tools get confused. The problems I hit so far.

1. rpmlint complaints about

In cannot answer such a question but maybe rephrasing it in more general terms
would help somebody to see a bigger picture. What to do if package X
is/contains an utility that acts as a controller for external machines with
various binary architectures and contains binary code to be executed on those
machines as data, where the binaries for various architectures are packaged
separately? I believe a similar question may be raised with respect to
firmware blobs.

Could we refrain from scrutinising binary objects installed in %{_datadir} for
that purpose? Should a special RPM tag %data be devised to qualify such

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread
  • No further messages