Martin Dummer <martin.dum...@gmx.net> writes: > Am 09.05.24 um 14:13 schrieb Sam James: > > Martin Dummer <martin.dum...@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.
It sounds like maybe you want to turn these into log messages (einfo - https://devmanual.gentoo.org/ebuild-writing/messages/index.html), and drop the "QA notice" prefix.
