----- "seth vidal" <skvidal(a)fedoraproject.org> wrote:
> I was thinking some more about the rpmguard/rpmlint/etc tests and
> looking around the tests subdir.
>
> rpmguard and rpmlint overlap in this weird way.
>
> rpmguard tests comparisons between old and new pkgs
> rpmlint tests just the new pkgs themselves.
>
>
> combining those under one umbrella seems to make the most sense.
>
> so you have:
>
> package-tests
> - comparisons/regression checks
> - *lintian checks
>
> For purposes of encouraging test authors it seems like it would make
> sense to make one interface for all of this.
>
> So, provide:
> - set of new pkgs
> - set of old pkgs
> - an object to use to spit back feedback (as described before)
>
> then the test author can choose to look at previous pkgs (or not) as
> they require and they don't have to learn two infrastructure.
>
> In this scheme them rpmlint check would just be another test that's
> run
> and happens to only act on the new pkg set.
>
> Is this worth pursuing?
>
> -sv
Seth,
thanks for an idea. Me and James already discussed that briefly a few
times and IIRC concluded that we would discuss it in more detail
some time in the future :)
It is true that rpmlint and rpmguard have many things in common. I also
took a lot of inspiration out of the former one when writing the latter
one. We could merge them together. I'm just not sure how much it would
complicate the interface. Also there are some other minor differences -
rpmlint checks package conformity to some guidelines, therefore it
can spit out meaningful errors. On the other hand there are no real
guidelines on how much the package can change in time, so rpmguard can't
really mark something as error, it can just output information messages
or warnings at best. But still that's fine I think.
We certainly have to speak with rpmlint's maintainer first - Ville
Skytta I think. And the most important question - now or some time
later? :) I agree it can be a nice future plan (it can be even a
summer coding topic, yay!), but currently our team has higher priority
in finishing AutoQA and implementing Package Update Acceptance Test
Plan, I think.
What do you say?