Last minute changes to rpm-4.0.3.

[Jeff Johnson <jbj JBJ ORG>]

Here's the CHANGELOG entries for rpm-4.0.3-0.61:

	- package version now configureable, default v3.
	- rename rpm libraries to have version with libtool -release.
	- revert rpmqv.c change for now.

Since each of these is going to introduce major changes into rpm-4.0.3
at the last possible moment, here's a short description of the problem
and rationale for the changes.

1) - package version now configureable, default v3.

rpm-4.0 changed the package version for a 3 to a 4. rpm-4.0.3 is going
to revert that change. What's being talked about is byte #5 in a package.
If byte #5 has a 3, then this is "v3 packaging", if byte #4 gas a 3, then
this is "v4 packaging". So, instead of byte #5 having a 4, there's gonna be a 3.

The rationale for the change is simple. Lots of people have been confused
by the change, and think that there's some deeper mystery behind rpm
packaging, and no matter how hard I've tried to explain (most recently
with LSB folks), I'm just not getting through. So I'm gonna change the
number back to a 3. The hope is that the discussion about rpm compatibility
will move behind the mind-numbing
	3 != 4
discussions. The potential benefit is that legacy versions of rpm will
be able to understand packaging produced by rpm-4.0.3. This is mostly
a vain hope, as there are many, many other incompatibilities in package
contents, that will be reflected in dependencies, paths, etc, but I'm tired
of being blamed for creating the (false!) illusion of a "3 != 4" incompatibility.

I also see no reason why backward compatibility all the way back to
rpm-2.5.x can't be implemented in rpm, and will do so as need dictates
and time permits.

2) - rename rpm libraries to have version with libtool -release.

Just in case it's needed, "ABI compatibility" means that an application
that uses rpmlib and rpm itself can be upgraded independently of each other,
with some hope that an application, like red-carpet, continues to "work".

rpm-4.0.3 shared libraries will have an explcit "-4.0.3" in the name, except
for libpopt, which still has a mostly compatible ABI. This means that I'm
going to give up the pretense that rpm has an ABI, and promise only to
maintain ABI compatibility within a single version, be that major and/or
minor, of rpm.

Increasingly, more and more people are trying to use rpmlib for their
own purposes. In order to provide a stronger guarantee of ABI compatibility,
needed to encourage development of non-RedHat, non-Linux, applications, I'm
going to have to change rpmlib, which, of course, breaks the ABI. There are
large changes looming for rpm, including
	a) a new type of digital signature based on header metadata only.
	b) replacing the existing header format with something like binary XML.
So, rather than trying to continue "sneaking around in the ABI", I prefer to
just confess that

	Yes, truly, rpmlib has nothing other than a de facto ABI, and makes
	no guarantee of binary compatibility beyond a given version whatsoever.

The API (i.e. what a program sees when compiled) is a slightly different matter,
and every effort will continue to be made to preserve a consistent API.
Note carefully that I promise only "consistency" in the API, caveat emptor.

Here's an absolutely trival example to illustrate why I must "break the ABI"
for shared libraries.

rpmlib.h has had the following declaration in the API for ages:
	extern const struct headerTagTableEntry_s rpmTagTable[];
with the corresponding array in the ABI. Since the array itself,
rather than a pointer to the array, is in the ABI, that effectively
means that no new tag can be added to rpm without breaking the ABI.
Since almost every "development" (as opposed to maintenance) effort
in rpm leads to a new tag, an ABI guarantee effectily prevents all
development.

In order to make the perfectly obvious change
	extern const struct headerTagTableEntry_s * rpmTagTable;
to put a constant length (i.e. sizeof(void *)) into the rpmlib ABI,
I have to break the ABI anyways. The only way out of this that I can see
is to retract the faux promise of ABI compatibility. Yes, I know about
weak symbols, but I see little reason to adopt that regimen for
the handful of applications that need/use rpmlib at the current time.
Yes, I could add a new name for a new array, but that breaks the ABI in a
different and sneaky -- been there, done that -- way.

In case it isn't obvious: The intent is to get a "proper" ABI for rpmlib
together as quickly as possible (although that may be a year), and then to
provide a stronger guarantee of ABI compatibility. That's the intent.

3) - revert rpmqv.c change for now.

The manner in which rpm deals with it's myriad command line options
is going to change. At the moment I have 2 main() routines that deal
with option processing in slightly different and incompatible ways,
with the added constraint that the rpm CLI must appear as it always
has (confusing, that's easy :-). Add to that the necessity of
having development/producition branches, and I've got 3 main()'s too
many.

Again, the rationale for the change is simple. rpm has outgrown
its early days where building, installing, querying, verifying, etc
could easily be maintained in a single binary. Building, in particular,
needs to be separated from installing, as rpm badly needs alternative
methods of producing rpm packages. Again, every effort can and will
be made to preserve (and document!) existing functionality, but
there will be breakage no matter what I do.

Ahh, now I feel better :-)

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC