RPATH status
Hans de Goede
j.w.r.degoede at hhs.nl
Sat Mar 10 08:45:39 UTC 2007
Toshio Kuratomi wrote:
> On Fri, 2007-03-09 at 22:28 -0500, Bill Nottingham wrote:
>> Hans de Goede (j.w.r.degoede at hhs.nl) said:
>>> rpmlint catches this, I'm sitll in favor of running rpmlint after a build,
>>> check the output against a whitelist of allowed output and if there is any
>>> output not in the whitelist, fail the build. We would need to integrate the
>>> same use of rpmlint in make <arch> from makefile.common then (or maybe
>>> first).
>> Do we really want to hold up builds on the rpmlint maintainer fixing
>> things in rpmlint?
>>
> If this is the same thought as past discussions, the whitelist is per
> package. I make a build. The rpms are run through rpmlint. The issues
> reported are compared against the previous build's rpmlint. If there
> are problems not previously whitelisted, the rpm is not pushed to the
> repo until the maintainer somehow adds the warnings to the whitelist or
> updates the spec so it no longer causes the error. (Maybe it's filling
> in a reason and submitting it to the packageDB. Maybe it's a specially
> formatted comment in the spec file. I don't know how people would want
> to implement the feature.)
>
My idea was to have a special file in CVS, which also gets tagged per
release just like the sources file.
Also notice that make <arch> should be patched first todo the same
thing, so that when a maintainer does a testbuild rpmlint is already run
and thus there are no surprises when rpmlint gets run on the buildsys.
I've been thinking about this for quite a while now actually as I very
regulary encounter packages with packaging errors which are caught by
rpmlint. And sometimes upstream causes packaging regressions like
introducing rpath in a new release. Automated QA is simply good, as long
as it doesn't get in the way and the whitelist makes sure it doesn't.
The whitelist should probably handle wildcards or regex, so maintainers
who really don't want this can simply put .* in the whitelist.
Regards,
Hans
More information about the devel
mailing list