Description of problem:
Version-Release number of selected component (if applicable):
The Source0 archive in the attached SRPM includes an ELF binary. rpmlint on the
SRPM doesn't produce an error.
Created attachment 150415 [details]
Hmm, I'm not sure if this is much of a problem if the ELF binary is not actually
used for anything, and checking whether it is used for something during package
build is beyond rpmlint's capabilities, I'm afraid.
Additionally, there is no infrastructure in rpmlint for extracting SourceX
tarballs and friends. And emitting warning about those binaries could lead to
people removing the binaries and shipping modified tarballs which cannot be that
easily verified against upstream after the deed is done, and that can be argued
to be a bigger problem than just using vanilla upstream tarballs and making sure
anything unwanted in them are not used.
Short version: if there's a patch, I can have a look, but it's unlikely I will
personally spend time on this anytime soon (and no promises about later either);
it's quite a bit of work for a smallish gain which can be also argued to be
harmful, depending on opinion.
Feel free to reopen here if you disagree and want to try convince me otherwise
(preferably with patches included ;)), or in upstream Trac
(http://rpmlint.zarb.org) if you want other rpmlint devs' opinions.
It's unclear to me whether it is required or not to remove binaries from source
distributions. This draft is available:
http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement but it is
unclear to me whether this covers the RPM or both the RPM and SRPM.
If it is required, there should be definitely be a check of this sort.
It it's not required, then we should make the packaging guidelines clearer in
This began when I recently repackaged a source tarball to remove a binary, and
rpmlint didn't warn that it was there to begin with. My reviewer told me to
remove it after I brought up the issue with him.
Personally, I don't care if the binary is in the source tarball because if
someone is messing with the source/srpm I generally look at it as "they must
know what they're doing". However, it is a good point that the binary could be
a payload for a virus or trojan and we certainly wouldn't want that to have the
possibility of that in our source.
You're on the packaging committee... you tell me :)
Seriously, if you don't mind, throw this topic in front of the committee at the