Filtering these warnings out is premature at the moment, I'll keep them around until there's an RHEL/EPEL release out whose rpm does the right thing without buildroot stuff in specfiles.  Until then, "rpmlint -I no-buildroot-tag" and "rpmlint -I no-cleaning-of-buildroot" should make it pretty clear (with rpmlint >= 0.91) to packagers when they can ignore these warnings.

I hate to reopen this ticket, but it seems a reasonable way to restart this discussion.  

The packaging committee talked a bit about this issue in our recent meeting.  The fundamental problem is that the utility of rpmlint as a required portion of the package review diminishes when it complains about packages even though they closely follow our templates and recommendations.  Everyone understands that it's not a generally solvable problem and that some false positives are going to happen, but there's really no ambiguity when it comes to something like the BuildRoot: tag.

So we're wondering if there's any compromise to be struck here.  One possibility raised at the meeting was to somehow let the user select add an option to check against either EPEL or modern Fedora guidelines, defaulting to whatever you're currently running.  Would you be amenable to a patch to allow that?  Do you have other suggestions as for how that kind of thing might be accomplished?

The meeting log is at http://meetbot.fedoraproject.org/fedora-meeting/2009-12-02/fedora-meeting.2009-12-02-17.14.log.html
The relevant discussion starts at 18:32:59.

Sure, that's possible.  For example something like this could work from user POV and wouldn't require that many/invasive changes to the rpmlint code either and the changes would be upstreamable:

When invoked as foo-rpmlint, instead of loading /usr/share/rpmlint/config rpmlint would load /usr/share/rpmlint/config.foo if it exists, otherwise /usr/share/rpmlint/config as usual.  Then we'd just install a few symlinks to /usr/bin that point to /usr/bin/rpmlint, let's say fedora-rpmlint or fpc-rpmlint and epel-rpmlint and add necessary code changes to make the desired config switching happen.  When invoked as plain rpmlint, it'd behave as it currently does.

But in addition to this, someone needs to maintain the specialized configuration files.  Often those files could just load /usr/share/rpmlint/config and make the necessary changes to the "base" configuration and be done with it.  I'd appreciate if someone (preferably from FPC) volunteered as a co-maintainer to maintain these config files in the rpmlint package as the guidelines evolve; I'm not promising to be available for that at the moment.

(In reply to comment #2)
> http://meetbot.fedoraproject.org/fedora-meeting/2009-12-02/fedora-meeting.2009-12-02-17.14.log.html

By the way, it seems that my position on this was not understood, these warnings will not stay around indefinitely.  Please see comment 1: "... until there's an RHEL/EPEL release out whose rpm does the right thing ..." which means at RHEL 6 time I intend to filter these warnings out from the Fedora rpmlint package anyway (assuming its rpmbuild does that right thing).

RHEL 6 isn't that far away which would make this particular issue moot, but if people think this distro/something specific configurability is necessary/desirable anyway, let's look into it.

That misinterpretation of your position was entirely my fault, and for that I apologize.

In any case, I'll work with FPC to see if we figure out if we can press some volunteers into service, or simply decide to make assisting with rpmlint a function of the committee.

Good.  By the way, if this config switching feature is going to be implemented along the lines in comment 3, the config files and symlinks don't even have to be included in the "main" rpmlint package, they can be maintained in a separate one that just requires rpmlint.

This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Created attachment 427728 [details]
Adds support for prefixed variants of rpmline

This patch adds support for prefixed variants of rpmlint, as described in comment 3.

If rpmlint is invoked as $prefix-rpmlint, it will look for /usr/share/rpmlint/config.foo, and if that file is found, it will load it instead of /usr/share/rpmlint/config. If that file is not found, it will load /usr/share/rpmlint/config. If rpmlint is not invoked as $prefix-rpmlint, it will load /usr/share/rpmlint/config (as normal).

Created attachment 427729 [details]
Fixed version of patch for prefixed variants of rpmlint

Fixed version of previous patch, pesky tab snuck in there.

Thanks spot, applied upstream with minor changes (allow hyphens in prefix and trailing ".py)": http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1799

rpmlint-0.99-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/rpmlint-0.99-1.fc14

rpmlint-0.99-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

So, now that we have a released Fedora with this capability, and also that RHEL6 is out, what happens next?

Does the rpmlint package grow el4-rpmlint, el5-rpmlint, etc. with their own config files?  What should the regular unprefixed "rpmlint" check?  (I'd hope it would be whatever's proper for the Fedora version it's built for.)  

I can do the work to set that up if you let me know what you'd like to happen.

First, I think discussing this on a mailing list (fedora-packaging?) would be better than here.  But here's some random thoughts anyway, in no particular order:

I'd prefer if the configs (perhaps including the main one) were maintained outside of the main rpmlint package, or alternatively someone to sign up as a rpmlint co-maintainer [1] to look after them.  If they're separate, the main rpmlint package could then have a "Requires: system-rpmlint-config" or something and the configs package could provide that.

My preference would be that the plain "rpmlint" would continue to be configured similarly as it is now, i.e. keep reporting issues that are known or possibly problematic in some current versions of Fedora and EPEL.

If the plain config would filter as few messages as possible and otherwise be generic enough, distro specific config files could all first pull in /usr/share/rpmlint/config with execfile(), and then apply their modifications on top of the generic config.

We could add let's say a fedora-rpmlint or rpmlint-fedora or something script that would some way figure out the dist it is running on and then just exec $dist-rpmlint if it exists.

All of this (rpmlint-fedora, $dist-rpmlint and their configs) could live in a separate package.

[1] Or even the primary owner - I don't insist at all to be in that role.  Actually I don't insist being involved with maintaining the Fedora rpmlint package at all, hacking it upstream would be enough for me...

rpmlint-1.0-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/rpmlint-1.0-2.fc14

rpmlint-1.0-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/rpmlint-1.0-2.fc13

rpmlint-1.0-2.fc13 has been pushed to the Fedora 13 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 rpmlint'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/rpmlint-1.0-2.fc13

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

rpmlint-1.0-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

rpmlint-1.0-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.