Bug 478907

Note that OpenPKG uses rpm-5.x, which is trying to eliminate
an abandoned data structure 12 years later aggressively (by not populating the lead
of *.src.rpm to demonstrably show that the information is not used).

Re-adding the lead information to rpm-5.x (as used by OpenPKG) to achieve
compatibility with whatever rpm.org rpm-4.6.0 (and rpm-4.4.2.3.4.5.6.7...)
is very not hard to achieve, and most definitely will be done as necessary.

However, the git check-in in 4.6.0 is doing a test that has never
been in any version of rpm before, and is in fact using info in a lead to test for a
SRPM in a new and different way.

In all cases, for all packages ever produced by RPM itself, the
single best (as in works everywhere and always) test is the non-existence
of RPMTAG_SOURCERPM. All binary packages have RPMTAG_SOURCERPM
for at least a decade, no SRPM includes that tag.

OpenPKG SRPM's also include RPMTAG_SOURCEPACKAGE explicitly in
a SRPM header, which was (until rpm-4.6.0 changed its test) sufficient
to achieve compatiblility with all versions of rpm other than rpm-4.6.0.

The oddball case of jclasslib package can be found in bug 475214, almost certainly not produced by rpm itself, or at least a modified rpm used. Up to the commit in question, rpm 4.6 would think of it as a source rpm too (as only RPMTAG_SOURCERPM was looked at), but 4.4.x and older do recognize it as a binary package due to looking into lead, although in slightly different way (note the system in bug 475215 was upgraded from F9, the package originally installed with rpm 4.4.x). 

We've a nice little mess here:
- both rpm.org and rpm5.org use mainly RPMTAG_SOURCERPM existence for determining type
- rpm5.org doesn't produce lead info at all
- rpm5.org adds explicit RPMTAG_SOURCEPACKAGE *if* built to do so
- rpm.org retrofits RPMTAG_SOURCEPACKAGE at runtime on packages determined as source, based on RPMTAG_SOURCERPM (non-)existence
- LSB (yeah yeah, I know...) stating that the type of rpm package is determined by the lead, RPMTAG_SOURCERPM is informational, ie "does not contribute to processing of package"

I'm not exactly overjoyed about depending on the info from lead either... but we've a package here that conforms to a written standard (obsolete as it may be), but just not to the unwritten de-facto standard used by rpm itself. And the package has worked up until now.

One possibility that would treat this as the oddball case it is: see if RPMTAG_RPMVERSION is present and if not, only then resort to using the lead for anything. RPMTAG_RPMVERSION is of course another "informational only" tag, but AFAIK all rpm versions always add it, so it's a fairly good indicator whether a package was produced with rpm or with something else.

RPMTAG_RPMVERSION is not in the lead is most of what I care.

And someone ought to point out the "oddball case" to whomever made the package.
rpm does not install partially damaged packages, and its not too hard to define
lack of RPMTAG_SOURCERPM as a form of partial damage no matter
how the package came to be installed on FC9.

You hopefully can understand, that I don't care that much about the developer mess you mentioned. You've made an exception in Fedora for jrpm created rpm packages, so another exception or workaround should not matter that much, right? I would like to see getting rid of this in Fedora rpm without breaking anything anywhere else - thank you.

Since when is Fedora *really* taking care regarding LSB? Didn't somebody of
your colleagues somewhen officially tell, that the LSB is anyway crap? ;-)

Panu, can we move forward with this bug, please? I really would like to see
this regression solved in a non-destroying way making everybody happy.

Panu, can you please show up on this bug report?

Currently it seems to me, that supporting a single jpackage created RPM
package is more important for Fedora rather compatibility with rpm5.org.

As to comment 5, and the reference to the dismissal of the LSB by 'spot', and the recent ones as to the FHS, I have worked rather hard to seek to draw Fedora folk into interest in LSB, and to address the criticism of the FHS to make the FHS relevant and able to be responsive to recent criticism.  

I take it from comment that the problem is 'jrpm created rpm' pacages do not implement all the header structures -- Shouldn't this be reassigned to whatever the owning package for the offnder, so that it may be fixed?

If bugzilla and rpm development under Red Hat are bent to serve the 'Balkanizing' political desires of part of Fedora, we are all lost.

Note that compatibility will be dealt with @rpm5.org if/when rpm-4.6.0 is
"officially" released. There are other incompatibilities in rpm.org's rpm-4.6.0
that are at least as important as discussing a value in an "abandoned" rpmlead
data structure.

Oh right, I'm complaining here about, that it seems to be more important, that 
a single jrpm created RPM package seems to be more important for Fedora rather 
compatibility with rpm5.org. Sorry jpackage guys, I meant jrpm. I got pointed,
that this is a huge difference. So jrpm not jpackage.

If you folks have finished flaming me for bogus lead in your packages causing problems for the time being, can we try to be constructive for a moment?

I turned the check around a bit, RPMTAG_SOURCEPACKAGE in srpms is sufficient to prevent from being thought as a binary no matter what the lead says which AFAICT takes care of this bug.

Like I said in comment #2 I've no love the lead either, but I do care about packages conforming to widely existing documentation continuing to work. The "weird" jrpm packages do fullfill the widely existing documentation about rpm file format, RPMTAG_SOURCERPM is documented as "information only". Thats the issue to me, not single package being more important than compatibility or lack or thereof with rpm5.org.

This issue does demonstrate the feebleness of checking against non-existence and zeros though. What would avoid this is Yet Another Tag in the header, explicitly stating the type of the package. Eg. RPMTAG_PKGTYPE, values 1 for binary and 2 for source or so and push it to get documented in LSB. When not present, fall back to whatever ping-pong-retrofit-guesswork an implementation chooses to do - such as simply taking whatever the lead says. Wont help with the existing package universe of course but it would avoid this kind of issue from showing up ever again for new packages.

Panu, thank you first for showing up and changing your type check. Do you have
a git commit for me, so that I can test/verify it?

Regarding the idea of e.g. RPMTAG_PKGTYPE: Maybe Jeff can explain how it is 
handled for rpm5.org - maybe you like the idea (or maybe you already know how
rpm5.org handles this, as it's open source, yes).

Here's the commit from 4.6.x branch: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=49c2e8a79d14181f0398f7f4d85bff4d69260f55

Unless something has very recently changed, AFAIK rpm5.org decides simply by (non-)existence of RPMTAG_SOURCERPM (which is what rpm.org did too before all this). Which is feeble as you cannot know by looking at a package whether the tag is left out on purpose or not, which is largely the reason why we have this bug :)

There are no flames from me here ... but if you insist, I will most
definitely flame you for making RPMTAG_FILEDIGESTALGO a scalar;
you could have *easily* added a new tag number without boogering
up a pre-existing (the work was done 2+ years ago) implementation
just because you can.

Just add RPMTAG_SOURCEPACKAGE to SRPMS during rpmbuild and be done with the issue.

Adding RPMTAG_SOURCEPACKAGE explicitly during build avoids the pokery-jiggery testing
for non-existence of Something Else, which has always been flawed
(but is in fact what has been done by RPM for years).

I see no reason for RPMTAG_PKGTYPE to be added to content. There are
already positive tests for "source" w RPMTAG_SOURCEPACKAGE, and
"binary" w RPMTAG_SOURCERPM.

No matter what identifier is devised, there will always be corner-cases,
like pubkey headers, and jrpm created "buggy" packages, and maliciously
fuzzed header content, etc.

No reliable "standard" exists for types of RPM packages, nor can RPM
packages be adequately semantically typed as "source", "binary", or ...
Consider the kernel-source package which was a "binary" RPM
containing "source" code, for one well known confusion.

Any enumeration of the characteristics of "source" or "binary" RPM
packages quickly identifies the jrpm as neither "source" nor "binary"
RPM package.

Re "recently changed" in comment #12:

rpm-5.0 was released @rpm5.org explicitly adding RPMTAG_SOURCEPACKAGE to
*.src.rpm headers for all vendors who wished compatibility with rpm-4.x. rpm-5.0
has _ALWAYS_ been that way.

Jeff, others flamed not you (as is quite obvious by reading the comments), that wasn't addressed to you.

The RPMTAG_FILEDIGESTALGO[S] clash is outside of the scope of this bug but just for the record: yes, it was a dumb thing from me, and is now resolved in rpm.org, 4.6.0 will go out with a different tag for it. Fortunately nobody uses it yet for anything but early testing.

Cool, one less issue for me to fix. I was really hoping you'ld achieve db-4.7.x, c'est dommage ...

There's still headerGet() with different arguments, I did squat that ELF symbol first,
but I'l leave that flammage for later. Deliberately poisoning API/ABI linkage just
means "Two men in, one man out." I most definitely plan my exit by walking out ...

rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rpm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1478

rpm-4.6.0-1 seems to solve my issue so far - thank you.

rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.