RPM Community Forums

Mailing List Message of <rpm-users>

Re: Single RPM database, multiple platforms

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 04 Mar 2009 - 03:40:52 CET
Message-id: <9667A5A8-3C17-4DD4-955B-D493F104B44A@mac.com>

On Mar 3, 2009, at 7:39 PM, Jeff Putsch wrote:

> Jeff,
> Thanks for the feedback, see below for more questions and guidance  
> requests...
> On Mar 3, 2009, at 3:40 PM, Jeff Johnson wrote:
>>> I'm installing custom built rpm packages for multiple platforms  
>>> (CPU-any-OS) on a single NFS shared filesystem. The platforms for  
>>> the packages are defined by CPU and OS as in the following example:
>> Careful, Berkeley DB needs to be built with fcntl locking __AND__
>> you need fcntl working across NFS for this deployment to be  
>> successful.
> Yes. I understand and am aware of the problem. I avoid Berkely DB  
> and use SQLite instead to minimize problems. Yes, I know it can have  
> problems too, but as numerous people have pointed out on this list,  
> it turns out to be good enough in practice.

As long as you are aware ...

>> Hmmmm, either
>> rpm -e foo-1.0-1.amd64-rhel3
>> or
>> rpm -e foo-1.0-1.amd64-rhel3
>> would be the command if you truly had distingushed architectures.
> Not sure what you mean here? What is a "distinguished architecture"?  
> For both packages %{arch} is "amd64", for one package %{os} is  
> "rhel3", for the other %{os} is "rhel4". To wit:

distinguished arch == the string in RPMTAG_ARCH (and compiled into rpm  
arch tables)
like "i386" "x86_64" etc.

All I can see is a string "amd64-rhel3", I do not know eher the  
are, whether its a single string, or (as you are pointing out now) its
a compound string.

>  % rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}-%{OS} 
> \n'
>  foo-1.0-1.amd64-rhel4
>  foo-1.0-1.amd64-rhel3
>  foo-1.0-1.sparc64-solaris8
>  % rpm -e foo-1.0-1-1.amd64-rhel3
>  error: package foo-1.0-1.amd64-rhel3 is not installed
>  % rpm --version
>  rpm (RPM) 5.1.6
>  % rpm --eval '%{_arch}-%{_vendor}-%{_os}'
>  amd64-any-rhel4
>  % rpm --showrc | grep amd64
>  build arch            : amd64
>  compatible build archs: amd64
>  install arch          : amd64
>  compatible archs      : amd64
>  macrofiles            : ... paths removed to save space ...
>   -1= _host_cpu	amd64
>  -14: _prefix	/usr/sepp/amd64-rhel4
>  -11= _target	amd64-rhel4
>  -11= _target_cpu	amd64
>  -14: _usrlibrpm	/usr/sepp/amd64-rhel4/lib/rpm
>  -14: l_prefix	/usr/sepp/amd64-rhel4
>  -14: l_prefix_static	/usr/sepp/amd64-rhel4
> I thought RPM treated %{arch} and %{os} equally, and that the  
> "platform"was a
> combination of arch, vendor, and os. I'm using "My Company Name" for  
> vendor
> (via Vendor: in the spec file), thereby making distinguishing parts  
> of the
> "platform" be arch and os. Perhaps I need to let "Vendor" default to  
> "any"?

RPM has never paid attention to RPMTAG_OS basically because
there's never been a need to do so.

Similarly, RPM only paid attention to RPMTAG_ARCH as an
compatibility attribute.

In both cases, the reason is similar: an rpmdb tracks
what is installed on a single machine, where there
is only one operating system, and only compatible
or non-compatible packages.

> I set the platform for a given system in the $prefix/etc/rpm/ 
> platform file (where $prefix is the root of my RPM install tree).  
> The value in that file is "ARCH-any-OS" where ARCH and OS are values  
> above.

Yes, RPM uses a platform string, which includes OS.

But the packages that have installed:
are indistinguishable becuase they have identical
name version release and architecture. RPM does
not distinguish packages based on operating system,
and os there's no means to erase.

> It looks to me as if that's not happening. It's much more likely I  
> don't
> understand what I need to do to properly define "platforms" for RPM  
> such
> that I can do what I'm trying to do. Any guidance on getting the  
> packages built with a "platform" or architecture such that rpm will  
> recognize them distinctly at removal time will be greatly appreciated.

What are you trying to do?

Why not use multiple databases on different paths, which include
a platform string in the path to the rpmdb, instantly avoiding
the problem that you are seeing, instead?

73 de Jeff
Received on Wed Mar 4 03:41:14 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.