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 - 07:23:31 CET
Message-id: <A8C9EA42-3CB5-4818-B8EF-088C3618EC52@mac.com>

On Mar 3, 2009, at 9:55 PM, Jeff Putsch wrote:

> On Mar 3, 2009, at 6:40 PM, Jeff Johnson wrote:
>> RPM has never paid attention to RPMTAG_OS basically because
>> there's never been a need to do so.
>
> Got it. There's the source of my confusion.
>
>> Similarly, RPM only paid attention to RPMTAG_ARCH as an
>> compatibility attribute.
>
> OK. Got it.
>
>> 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.
>
> OK.
>
>>> 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?
>
> Well... I need to put together a packaging system that manages  
> multiple architectures (platforms) at once. The packages are  
> installed in a shared disk space (NFS storage) and the directory  
> structure being used needs to be backwards compatible with one  
> already in place. We use the --prefix and --exec-prefix style split  
> for most packages.
>
> The management of the installed packages needs to happen from one or  
> more computers sharing the storage and the management platforms may  
> be of different OSes and architectures for a given NFS repository.
>
> I need reporting, etc. from these hosts.
>
> Since RPM pretty much gets the job done (the key is to get the  
> "RPMTAG_ARCH" defined right), it seems much easier to me to have a  
> single rpm database for this shared tree, than multiple trees and  
> wrappers around RPM to make sure the right thing happens multiple  
> times, or to take the reporting output and merge it properly (e.g. a  
> "noarch" package installed in multiple trees should be reported only  
> once). With a merged tree and RPM handling the packaging the  
> "multiple" part of the problem takes care of itself.
>

Well try splitting the multiple platforms into multiple databases.

(aside)
You are going to find that platforms with different OS are
largely disjoint (i.e. will never share the same package meaningfully)
no matter what. Unifying the packages into one database, or one
report, gains little that I can see other than lazy convenience.

Adding CPU-VENDOR-OS macros into the rpmdb path is quite easy.

I just tested the following:

[root@wellfleet ~]# rpm -q --target foo popt
popt-1.13-4.fc10.i386
[root@wellfleet ~]# rpm -q --target foo --dbpath '/var/lib/% 
{_target_cpu}' popt
package popt is not installed
[root@wellfleet ~]# ls -ald /var/lib/{rpm,foo}
drwxr-xr-x 2 root root 4096 2009-03-04 01:04 /var/lib/foo
drwxr-xr-x 2 root root 4096 2009-01-22 14:25 /var/lib/rpm
[root@wellfleet ~]# rmdir /var/lib/foo
rmdir: failed to remove `/var/lib/foo': Directory not empty
[root@wellfleet ~]# rm -rf /var/lib/foo
[root@wellfleet ~]# ln -s rpm /var/lib/foo
[root@wellfleet ~]# rpm -q --target foo --dbpath '/var/lib/% 
{_target_cpu}' popt
popt-1.13-4.fc10.i386

Which means that if you do
	echo '%_dbpath /var/lib/%{_target_cpu}-%{_target_os}' > /etc/rpm/ 
macros.dbpath
then you will have 1 rpmdb path for managing each CPU-OS platform.

Installation and/or --query reporting for each platform then needs
	--target foo
or
	--target foo-bar
added with the command. If you don't want to have to add --target  
explicitly,
then configure a popt alias in /etc/popt to hide the added option.

Finally, for all-platform reporting, write some wrapper scripts to loop
over all the platforms, invoking whatever --query commands you want,
and doing whatever uniqification is desired.

Thats the approach I would take.

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