On Wed, Aug 24, 2022 at 10:08:27AM +0200, zimoun wrote: > Hi Vagrant, > > On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian wrote: > > > But, because there is no way to silence a particular inappropriate > > suggestion from guix lint, it becomes noise, and each person evaluating > > the results of the package in the future then needs to take time to > > figure out if guix lint is wrong, or something should be changed. > > Do you have some packages as example? In order to be concrete about the > false-positive and how to programatically fix them. > > For instance, do you mean exclude on specific checker for one specific > package? Or teach one specific checker for one specific package in > order to avoid an error specific to this package running this specific > checker? We have lint-hidden-cve. We also have a number of packages where there is a string that is just too long but can't reasonably be cut shorter. > > > The downside is this becomes one more thing to maintain... in exchange > > for making the output having a higher degree of relevency in "guix lint" > > output, so you can be more confident that someone hasn't already looked > > at a given issue and decided it was best to just ignore it (not that > > that will not ever happen anymore, but still). The 'properties' field isn't mandatory, so if we just didn't add something it wouldn't be a big deal. > > The cost for a poor maintenance is low compared to the benefit, IMHO. > > For instance, it is boring to run massive lint: > > 1. because “guix lint” does not support the option --manifest > 2. because “guix lint” reports some false-positive messages > > > Cheers, > simon > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted