On Apr 10, 2011, at 11:42 AM, Per Øyvind Karlsen wrote:
>>
>> This has just happened in Mandriva Cooker, where %{_arch}
>> happened to end-up with "i586" not "i386" (the correct value afaik).
> First and only time it has happened, related to me wiping away the
> same macros maintained for mandriva specifically from rpm-setup,
> ie. a rpm bug. </sarcasm> ;p
The incidence isn't as important as the experience.
I used to build rpm all the time and tried to
have rpm self-configure from information available
in the build system (up to and including trapping
on SIGILL when asm voo-doo happened to encounter
a buggy flashing on a cpu. Yes "segfault" is/was
the means of identifying ppc64 cross-dressed as ppc32).
I've gotten burned so so so many times because --
when you convolve information from build system
into a per-package build -- then the packaging breakes EVERY time
the build system is misconfigured.
And the answer is no where near as simple as claiming
Mandriva build systems *NEVER* brak, are *ALWAYS*
perfectly configured.
KISS instead: the whole issue can be avoided is %{_arch} isn't
used with %multiarch but rather make multiarch packages per-arch
with hardwired "i386" strings in paths if that is what you choose
to do.
ANd even KISSier is patching /usr/include/*.h so that
source is arch independent. If you send patches upstream
there's even hope of fixing the problem everwhere and always.
RPM "file conflict" detection is no package management "feature" imho.
> hehe
>>
>> <sarcasm>
>> And for extra speshul painfulness on my own aging box, libcpuinfo
>> has decided to put "pentium4" into varous arch-related configgery
>> in order to assist me with RPM configgery.
>> </sarcasm>
> The pentium4 macros was already part of cpu-os-macros.tar.gz before
> me touching it, otherwise I wouldn't have added it.. :p
I do not use cpu-os-macros at all. I quite well know what
evil lurks within. I ripped out cpu-os-macros at my
first opportunity @rpm5.org and have continued on the path
RPMTAG_ARCH is DEAD! DEAD! DEAD!
and have negative interest in returning to paths already well known.
>>
>> You WILL got nutso if you attempt Mandriva multiarch packaging
>> policy like this in Poky imho. Cleaner/easier is to patch out
>> (or use) @redhat derived packaging instead.
> Fixing is of course preferred and often what is being done, but
> maintainers doesn't always have the necessary insight and knowledge
> to fix this, which makes it convenient to workaround it easily.
> Detection during build is useful either direction. :)
>>
>> But you are not using rpmbuild w Poky so it hardly matters.
>>
> Regards,
> Per Øyvind
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
