RPM Community Forums

Mailing List Message of <rpm-devel>

Globally persistent package identifiers

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 14 Jan 2009 - 18:07:27 CET
Message-id: <917D43F0-37E9-48BD-BCAF-B97EA71D3518@mac.com>
I have an RFE through e-mail from OpenPKG to support
a means to propagate the original RPMTAG_SOURCEPKGID
through a
	rpmbuild --rebuild ...
invocation for persistent package tracking.

The implementation will parallel what is already being done
with RPMTAG_ORIGINTID (the timestamp id for the 1st installation)
vs. RPMTAG_INSTALLTID (the timestamp id for the current installation).

So a new RPMTAG_ORIGINSOURCEPKGID to carry forward the header+payload
*.src.rpm MD5 digest for tracking purposes persistently through
	rpmbuild --rebuild

But this isn't the first, nor will it be the last, RFE for RPM
to propagate identifiers associated with a package persistently
and reliably throughout a package's lifetime.

What I'd like to start planning for is how to handle the
(perfectly predictable) RFE's into the future.

There are two approaches to globally persistent package identifiers  
(GUPI for short):

	1) let every vendor do their own thing in RPM however the vendor  
wishes.

	2) attempt a common approach in RPM that accomodates existing known  
needs.

Clearly I'm an advocate of 2), if, for no other reason, that the  
approach is
ultimately less work and more likely to be immediatley (as in next 2-3  
years)
useful imho.

But here are the means that already exist to accomodate 1) as a GUPI  
approach in RPM:

  1) arbitrary tags can be configured and used however one wishes.
  2) arbitrary tag data validation with analogues of %package_Name are  
in place.

What still needs doing is
   1) defining (i.e. parameterizing) how arbitrary tags are inheirited  
into binary sub-pkgs
   2) defining (i.e. parameterizing) how arbitrary tags can be  
propsgated from source -> binary pkgs.

And what can't be done at all by RPM with approach 1) (because of  
"arbitrary" opaqueness) is
to document tag values or usage cases or inheiritance patterns or  
anything else.

The most noteworthy GUPI implementations (imho) that are being  
attempted by vendors are
from OpenPKG and Wind River and Fedora and OpenSuSE.

OpenPKG is (at least, I do not speak for OpenPKG) attempting to track  
package build dependencies in
spite of static linkages (where RPM does not provide ELF symbol  
dependencies).

Wind River is attempting tracking configuration changes using digests.  
Most of
what is being attempted @windriver.com is described (without  
attribution, I do
not speak for Wind River) here:
	http://rpm5.org/community/rpm-devel/3092.html

Fedora 9 introduced a "build id" attached (more or less, better needs  
to be done)
from the GCC tool chain into *-debuginfo packages.

And OpenSUSE has something which appears to be very similar to a  
"build id" buried
into RPMTAG_DISTURL (which is not at all the right tag, I will  
renumber RPMTAG_DISTURL
to preserve the original intent as soon as I can get sufficient  
details about what
the SuSE desired content actually is).

All I can say from an RPM POV regarding GUPI approach 1) is
	You guys really should talk to each other about what you are doing.
and of course
	Good luck!

I have more to say about GUPI approach 2), none of it very startling,  
RPM has
carried
	RPMTAG_PKGID
	RPMTAG_HDRID
	RPMTAG_FILEID
around for years preparing for a GUPI approach. And sure you can  
always use NEVRA
identifiers forever if you wish, all the featlest/bugtures associated  
with NEVRA
identifiers are definitely understood.

So which GUPI approach, through "arbitrary" tags, or through a common  
mechanism?

Note that the two approaches are not exclusive, just more work than  
necessary.

73 de Jeff
Received on Wed Jan 14 18:07:49 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.