[prev in list] [next in list] [prev in thread] [next in thread]
List: rpm-devel
Subject: Re: [CVS] RPM: rpm/lib/ rpmrc.c
From: Per_Øyvind_Karlsen <pkarlsen () rpm5 ! org>
Date: 2009-03-18 21:08:59
Message-ID: 534660c60903181408o3629e7a2j8b37e47792b7da19 () mail ! gmail ! com
[Download RAW message or body]
2009/3/17 Jeff Johnson <n3npq@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
[Attachment #3 (text/html)]
<div class="gmail_quote">2009/3/17 Jeff Johnson <span dir="ltr"><<a \
href="mailto:n3npq@mac.com">n3npq@mac.com</a>></span><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <div style=""><div class="im"><br><div><div>On Mar \
17, 2009, at 2:02 PM, Per Øyvind Karlsen wrote:</div><blockquote type="cite"><div \
class="gmail_quote"><font color="#000000"><br></font><div>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.<br> <br></div></div>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. :)<br> </blockquote></div><br><div><br></div></div><div>The \
terms "simple" and "easy" have a way of evolving into \
"works"</div><div>which then morphs into "used" which then \
becomes "production"</div> <div>concrete with legacy issues etc etc \
etc</div><div><br></div><div>AFAIK, the only flaw that you are unhappy with in the \
existing miRE patterns</div><div>is that you want different /etc/rpm/platform \
patterns (and scoring), dependent</div> <div>on, say, whether the One True Arch! is \
"i386" or "x86_64".</div></div></blockquote><div></div><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <div style=""><div></div><div><br></div><div>ATM, \
patterns follow the CPU-VENDOR-OS-GNU platform identifier</div><div>in \
/etc/rpm/platform so that I did not have to be bothered explaining</div><div>a whole \
lotta goop to lusers while attempting to get rid of rpmrc files.</div> \
<div><br></div><div>But there's literally no reason why that convention cannot be \
changed</div><div>to move the platform affinity patterns to another path that is \
macro</div><div>expanded including %{_target_cpu} and the rest of the platform macro \
goopiness.</div> <div><br></div><div>E.g. put your i386 affinity patterns into \
/etc/rpm/affinity.i386, similarly x86_64,</div><div>and then trick up a diversion in \
/etc/rpm/platform as (literally)</div><div><br></div><div><span style="white-space: \
pre;"> </span>i386-unknown-linux-gnu<br> </div><div><span style="white-space: \
pre;"> </span>/etc/rpm/affinity.%{_target_cpu}<br></div><div><br></div><div>diversion \
== treat any line that starts with '/' as a path to read and \
insert.</div><div><br></div><div> That isn't very hard to do at \
all.</div><div><br></div><div>73 de Jeff</div></div></blockquote></div>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.<br> 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.<br> 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.<br> 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.<br><br>--<br>Regards,<br>Per Øyvind<br>
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic