I've seen this issue handled in the past by breaking up the RPM packages into
binary arch/os components and non arch/os common packages..
That doesn't solve upgrade issues directly, but may be work considering as you
migrate your products to newer versions in the future.
Jeff Putsch wrote:
> 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, the
> other oses will not know it. An rhel4 package could nuke the stuff the
> rhel3 package installed, the rhel3 package could then remove stuff the
> 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 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.
>>> Jeff Putsch
>>> Email: email@example.com
>>> Office: 503.267.5480
>>> Horse ... Water ... Drink.
>>> RPM Package Manager http://rpm5.org
>>> User Communication List firstname.lastname@example.org
>> RPM Package Manager http://rpm5.org
>> User Communication List email@example.com
> Jeff Putsch
> Email: firstname.lastname@example.org
> Office: 503.267.5480
> Horse ... Water ... Drink.
> RPM Package Manager http://rpm5.org
> User Communication List email@example.com
Received on Wed Mar 4 18:29:37 2009