On Mar 10, 2008, at 5:32 AM, Martin Nicolay wrote:

> Hi!
>
> Is there a way to archive database compatibility with older  
> versions (rpm4
> / rpm3)?  We need to support many different Linux and SunOS  
> versions and
> would like to use the same packaging software for all systems.
> Unfortunately we have used the rpm proliferated by the distro for  
> our own
> software, so the system-packages and our own packages are within  
> the same
> database.  If we use the new and shiny rpm5 for updates of our  
> software,
> hell breaks loose for system updates (unless database compatibility es
> archived).
>

There are ways, yes.

Howver, if you want a universally compatible, seamless, drop-in,  
vendor-compatible,
version of rpm (who doesn't?), that cannot be achieved without vendor  
participation.

There are no vendors at rpm5.org. Hence compatibility is impossible.

There are 2 compatibility issues that need figuring: rpmdb  
compatibility, and
rpm "feature" compatibility.

In general, Berkeley DB provides backward, but not forward  
compatibility.
That means a newer version of Berkeley DB can usually read an old  
database, but not
vice versa.

Your vendor set, particularly since it includes SunOS (w rpm-3.0.4),  
spans
essentially every modern release of Berkeley DB, and so includes every
possible Berkeley DB compatibility issue. All the issues are quite  
carefully
documented, and Berkeley DB always supplies db_dump/db_load so that
conversions are possible. However conversion is not the same as  
"compatible".

There are several approaches to rpmdb compatibility:

1) Use whatever rpm+bdb the vendor supplies.
	Yes that is what you are trying to avoid. But you likely have ~5 or
	so distributions, so its is certainly feasible to design a process
	that distributes ~5 copies of packaged software, one for each vendor.

2) Coexisting vendor <-> custom rpm.
	rpm's database needs are rather modest, so it is quite feasible to
	build ~5 versions of rpm-5.x, with the same version of Berkeley DB
	used by the vendor's version of rpm.

(aside)The one notable exception is rpm-3.0.x, as used by Sun and IBM  
and old SuSE, which used
	db-1.85. All Berkeley DB releases for years have not supplied  
db-1.85 compatibility
	(except through db_dump/db_load conversion). Most rpm-4.0 versions  
have support for
	both db-1.85 and whatever Berkeley DB version was current when  
released.

	The two issues that would need deciding for coexisting vendor <->  
custom rpm are
	1) what version of Berkeley DB to build with?	Answer: same as  
vendor's rpm.
	2) what paths to use when installing?	Answer: don't collide with  
vendor paths.

	A typical answer usually involves deciding whether the vendor's or  
the custom rpm
	is the "production" version, and installing the other version on a  
different path.
	As long as the rpmdb can be shared, the two versions of rpm can  
interoperate
	because they use the same version of Berkeley DB.

3) Replace the vendor's rpm everywhere.
	I can supply details if desired, but I suspect that replacing is  
infeasible for you.

The other compatibility issue is "new and shiny rpm5" features.  
Features and compatibility
are always at odds: old version(s) will lack support for new features.

Typically that means choosing the balance point between features <->  
compatibility,
and then identifying the version of rpm that supplies the needed  
features.

That's the general statement of the problem. I can supply additional  
specific details
whenever.

Your hardest compatibility issue is with Sun, IBM, and old SuSE using  
rpm-3.0.x. Conversion
to rpm-4.0.x will simplify your problem space (imho), and that's what  
I would suggest.

hth

73 de Jeff