RPM Community Forums

Mailing List Message of <rpm-users>

Re: Single RPM database, multiple platforms

From: Jeff Putsch <putsch@mxim.com>
Date: Wed 04 Mar 2009 - 08:05:23 CET
Message-Id: <D0E9892F-1527-461C-BCAE-7C2CD7EFFC6C@mxim.com>

On Mar 3, 2009, at 10:23 PM, Jeff Johnson wrote:
 > 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.

Well, let's see... We have several commercial software packages that  
we repackage and distribute via this shared directory tree. At a high  
level of abstraction, with sizes of each category of files listed,  
these packages often look like this:

    /path/to/vendor/tool_v1/shared   1.0G    (noarch)
    /path/to/vendor/tool_v1/arch1    3.0G
    /path/to/vendor/tool_v1/arch2    3.0G
    /path/to/vendor/tool_v1/arch3    3.0G

Now, for this particular tool we have 11 versions of this tool  
installed simultaneously. It is quite meaningful to track all the  
architectures in one DB, though not impossible to track via multiple  
DBs. The key is a single platform needs to be able to generate queries  
and reports for all platforms installed into the "DB", be it multiple  
DBs or a single DB and the people using the setup do not need to, nor  
will they, know the platform names.

Anyways as you said it's probably just laziness on my part.

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

Good to know..

> 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.

The popt alias idea is interesting, but not viable since I may be  
installing managing amd64-rhel4 packages "on"/"from" a sparc64- 
solaris8 platform.

> 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.

That's most likely what's going to happen.

Thanks for the feedback and ideas.

Jeff Putsch
Email: putsch@mxim.com
Office: 503.267.5480
Horse ... Water ... Drink.
Received on Wed Mar 4 08:05:26 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.