Am 09.05.24 um 14:13 schrieb Sam James:
> Martin Dummer<martin.dummer@gmx.net>  writes:
>
>> Maybe we can agree that the qa-warnings in vdr-eclass make more sense if i change them to "eawarn" or "einfo"?
>>
> Sure, make them eqawarn.

Hmm - current state of vdr-plugin-2.eclass is: there are many "eqawarn"
in there.



>> In my opinion, most plugins in the vdr context will practically not develop any further anyway. It is more important to
>> keep the current status of vdr-software in the ecosystem up to date as well as possible.
>>
>> So I need a practical useful approach instead of a fundamental discussion please.
> My point is that the QA warnings should exist, and you can worry about
> making them "developer-only" in future. Right now, they seem useful, and
> the things they flag need to be addressed.
>
Basically yes, but here (vdr-plugins) the qawarn are used more in a way
"to remind the plugin developers to adapt their sources to newer vdr
build environment" or "the way i18n implemented has changed"

The eclass fixes these problems with standardized quirks, the "equawarn"
messages show when these quirks are applied.

IMHO its not necessary to tell that to any user, only for interested
packagers when they are bored and look out for some extra work. That's
why I made the warnings conditional, printed out when the variable
"VDR_MAINTAINTER_MODE" is set to a not-empty value.

Finally, I am interested in an opinion whether this is acceptable or
not, otherwise I tend to remove the warnings at all.