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.
>> 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.
Thanks, again, for clearing up what RPM keys off of! I really
appreciate getting that straightened out.
Horse ... Water ... Drink.
Received on Wed Mar 4 03:55:37 2009