On Mar 4, 2009, at 6:19 AM, Mark Hatle wrote:
> I have attempted something similar in the past, however on the same
> OS. Different databases made it easier to manage the components.
> A simple wrapper for the RPM command line items would allow you to
> specify (either automatically via uname, or manually such as --os=)
> and then dynamically switch the database. This would be a much
> safer solution as well.
Understood. The part I'm "struggling" with is the shared directory
tree that we manage. This tree has a platform independent part and a
platform dependent part. If I use different databases then the
following scenario becomes problematic:
If packages for rhel3 install stuff in platform independent part,
other oses will not know it. An rhel4 package could nuke the stuff
rhel3 package installed, the rhel3 package could then remove stuff
rhel4 package depends upon.
It think this means I'd need a separate database for noarch that is OS
From Jeff's description of controlling the database locations via cpu/
os or both I think I can do what I need and use separate databases.
We'll just have to make sure an RHEL3 package only installs in the
RHEL3 area and not in the platform independent area.
> Jeff Putsch wrote:
>>>> 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
>> 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.
>> Jeff Putsch
>> Email: email@example.com
>> Office: 503.267.5480
>> Horse ... Water ... Drink.
>> RPM Package Manager http://
>> User Communication List rpm-
> RPM Package Manager http://rpm5.org
> User Communication List firstname.lastname@example.org
Horse ... Water ... Drink.
Received on Wed Mar 4 17:54:46 2009