Re: guix lint should support overrides

[Efraim Flashner]

On Wed, Aug 24, 2022 at 10:08:27AM +0200, zimoun wrote:
> Hi Vagrant,
> 
> On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian <vagrant@debian.org> 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   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature