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 arch-independent-package-contains-binary-or-object.
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 items? Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org