I have an RFE through e-mail from OpenPKG to support
a means to propagate the original RPMTAG_SOURCEPKGID
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
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
2) attempt a common approach in RPM that accomodates existing known
Clearly I'm an advocate of 2), if, for no other reason, that the
ultimately less work and more likely to be immediatley (as in next 2-3
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
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
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
Wind River is attempting tracking configuration changes using digests.
what is being attempted @windriver.com is described (without
attribution, I do
not speak for Wind River) here:
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
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
I have more to say about GUPI approach 2), none of it very startling,
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
identifiers are definitely understood.
So which GUPI approach, through "arbitrary" tags, or through a common
Note that the two approaches are not exclusive, just more work than
73 de Jeff
Received on Wed Jan 14 18:07:49 2009