2009/3/17 Jeff Johnson <n3...@mac.com>

>
> On Mar 17, 2009, at 2:02 PM, Per Øyvind Karlsen wrote:
>
>
> Yeah. you're right, I've had that thought myself more than once already,
> but my initial focus has been to just do something simple, fairly minimal
> and working before making it into something nice and sane in addition.
>
> Using libcpuinfo OTOH is something I'm planning on sticking with as it's
> portable and easy enough to maintain without bizarre syntax and any hacks
> which might be used will anyways be kept outside of rpm. :)
>
>
>
> The terms "simple" and "easy" have a way of evolving into "works"
> which then morphs into "used" which then becomes "production"
> concrete with legacy issues etc etc etc
>
> AFAIK, the only flaw that you are unhappy with in the existing miRE
> patterns
> is that you want different /etc/rpm/platform patterns (and scoring),
> dependent
> on, say, whether the One True Arch! is "i386" or "x86_64".
>

> ATM, patterns follow the CPU-VENDOR-OS-GNU platform identifier
> in /etc/rpm/platform so that I did not have to be bothered explaining
> a whole lotta goop to lusers while attempting to get rid of rpmrc files.
>
> But there's literally no reason why that convention cannot be changed
> to move the platform affinity patterns to another path that is macro
> expanded including %{_target_cpu} and the rest of the platform macro
> goopiness.
>
> E.g. put your i386 affinity patterns into /etc/rpm/affinity.i386, similarly
> x86_64,
> and then trick up a diversion in /etc/rpm/platform as (literally)
>
> i386-unknown-linux-gnu
> /etc/rpm/affinity.%{_target_cpu}
>
> diversion == treat any line that starts with '/' as a path to read and
> insert.
>
> That isn't very hard to do at all.
>
> 73 de Jeff
>
I wasn't really unhappy about the platform scoring, that's okay enough, what
I was unhappy with was the inability to set default target platform for
building without platform score being affected, something that was possible
with buildarchtranslate.
This was only one of the issues, the main thing which I was unhappy about
was really the need for /etc/rpm/platform which needs to be maintained
manually by the user and makes it really hard for distributions to support
compatibility with several archs.
Runtime detection of this and the ability to override this with
/etc/rpm/platform is what is currently done in Mandriva Linux. This makes
rpm easier to maintain for the distribution, but the code in rpm for this is
as you said earlier really ugly and horrible to maintain, libcpuinfo solves
this by doing this outside of rpm and the code is much nicer and easier to
maintain as well, leaving only a minor amount of code in rpm to maintain.
This code sure has room for improvement, but it's satisfactory for my needs
for now and makes it possible for me to import rpm5 to Mandriva Linux with
consistent behaviour wrt rpm 4.6.0.

--
Regards,
Per Øyvind

Reply via email to