On Jul 23, 2011, at 3:13 PM, Sriram Narayanan wrote:
> Thanks for your responses, everyone.
>
BTW here's a response to your smart-list question re arch scoring:
> Yes, I get this very output, but I don't know what it means. I need to
> study rpm internals and read the docs better!
The "platform affinity" patterns (See Tim Mooney's example) are used also to
set the archscore.
The arch score was original devised as a simple metric to, say,
Prefer *.i586.rpm packages on an i586 architecture.
when given all the usual *.{i386,i486,i586,i686}.rpm package choices.
The patterns in /etc/rpm/platform (except for the 1st line which is a string)
are used to determine the arch score, which is literally nothing more
that the line number in /etc/rpm/platform of the pattern that matches.
The arch score is just an integer with "lower is better", the value has
always been arbitrary.
The preference metric implemented in arch score has always been a bit clunky.
Mostly its a design flaw:
Preference is multi-dimensional and cannot be reduced to a single
integer.
(aside)
For the picky pedantics: almost anything can be mapped onto integers somehow,
but in the real world, preference has many dimensions and one can often end up
with conflicting preferences. Consider
I love pistachio ice cream.
I hate food that makes me fat.
and I defy you to propose a metric solution that leads to me eating chocolate
ice cream because that's all that is available. ;-)
I hope that helps to answer what arch score is about. Almost all issues can
be ignored as long as you are using only "no arch" and "i86pc" packages.
You (or rather smart) will attempt to use arch score to choose the right
kernel package, or perhaps some crypto package optimized for an architecture
like
openssl, but otherwise arch score (and the patterns in /etc/rpm/platform) can
largely be ignored.
> I had to place "i86pc-pc-Solaris" in /etc/rpm/platform (I'm using a 32
> bit build for the time being).
>
> I also had to place /etc/rpm/macros and customize the following:
> %_arch i86pc
The %_arch macro is/was used to set the "canonical arch", like "i386" on an
i686 cpu.
Mostly useless these days (but there's still some distros that use, but
not for what it was intended for).
> %_build_arch i86pc
> %_vendor pc
> %_os Solaris
>
All of the above settings should be consistent with the CPU-VENDOR-OS-GNU
string (i.e. the first line in /etc/rpm/platform). The main reason why
Anders suggested that you use that file is so you can control for
certain values that if NOT specified, end up coming from uname(2)
with a translation mapping implemented in C whose values cannot be relied on,
particularly on non-linux platforms.
> With this, I now have the smart package manager working.
>
Congrats!
73 de Jeff
> -- Sriram
>
> On Sat, Jul 23, 2011 at 1:44 AM, Jeff Johnson <n3...@mac.com> wrote:
>>
>> On Jul 22, 2011, at 3:59 PM, Tim Mooney wrote:
>>
>>> In regard to: What should the contents of /etc/rpm/platform be ?, Sriram...:
>>>
>>>> sriram@ram-oi:/usr/src/rpm/RPMS/i86pc$ uname -a
>>>> SunOS ram-oi 5.11 oi_147 i86pc i386 i86pc Solaris
>>>>
>>>> sriram@ram-oi:/usr/src/rpm/RPMS/i86pc$ ls /usr/src/rpm/RPMS/i86pc/
>>>> autoconf-2.68-1.i86pc.rpm cmake-2.8.5-1.i86pc.rpm nginx-1.0.4-1.i86pc.rpm
>>>> axel-2.4-1.i86pc.rpm git-1.7.6-1.i86pc.rpm repodata
>>>>
>>>> I build some packages already. (I now install from rpm packages only).
>>>>
>>>> rpm --eval "%{_arch}-%{_vendor}-%{_os}%{?_gnu}"
>>>> i386-pc-solaris
>>>
>>> On my x86_64-sun-solaris2.10 workstation I have
>>>
>>> 02:46 PM dogbert ~$cat /etc/rpm/platform x86_64-sun-solaris
>>> x86_64-sun-solaris2.10
>>> i686-sun-solaris
>>> i686-*-solaris
>>> i686-sun-solaris2.10
>>> x86_64-[^-]*-solaris.*
>>> noarch-[^-]*-.*
>>> [^-]*-[^-]*-noos
>>>
>>
>> Oooh nice! a worked example of platform affinity! Thank you!
>>
>> I always skip that explanation initially.
>>
>> BTW, there's negative affinity in /etc/rpm/platform patterns too if you
>> prefix a pattern with !
>> it inverts the sense of the match.
>>
>> hth
>>
>> 73 de Jeff
>>> Not all of those are relevant (or probably even valid...), but you get
>>> the idea.
>>>
>>> You may also want to consider overriding %_arch, %_vendor, and potentially
>>> other platform-related macros in your host-specific RPM macros (probably
>>> /etc/rpm/macros).
>>>
>>> Tim
>>> --
>>> Tim Mooney tim.moo...@ndsu.edu
>>> Enterprise Computing & Infrastructure 701-231-1076 (Voice)
>>> Room 242-J6, IACC Building 701-231-8541 (Fax)
>>> North Dakota State University, Fargo, ND 58105-5164
>>> ______________________________________________________________________
>>> RPM Package Manager http://rpm5.org
>>> Developer Communication List rpm-devel@rpm5.org
>>
>> ______________________________________________________________________
>> RPM Package Manager http://rpm5.org
>> Developer Communication List rpm-devel@rpm5.org
>>
>
>
>
> --
> Belenix: www.belenix.org
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
