Ludovic Courtès (2015-07-16 22:08 +0300) wrote:
> Alex Kost <alez...@gmail.com> skribis:
>
>> Eric Bavier (2015-07-16 12:40 +0300) wrote:
>>
>>> On Thu, 16 Jul 2015 14:17:22 +0300
>>> Alex Kost <alez...@gmail.com> wrote:
>>>
>>>> --- a/gnu/packages/base.scm
>>>> +++ b/gnu/packages/base.scm
>>>> @@ -58,7 +58,7 @@
>>>> (sha256
>>>> (base32
>>>> "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
>>>> (build-system gnu-build-system)
>>>> - (synopsis "Hello, GNU world: An example GNU package")
>>>> + (synopsis "Example GNU package")
>>>
>>> I have not looked over then entire patch, but this one caught my eye.
>>> We need to make sure that any changes you make here will not be
>>> expediently overwritten by an invocation of `make sync-descriptions`.
>>> I believe this has happened in the past already.
>>
>> I changed this synopsis because "guix lint" doesn't like when the first
>> word of a synopsis is the package name.
>
> The problem is that this rule sometimes conflicts with the
> ‘gnu-description’ checker (aka. ‘make sync-descriptions’), which checks
> upstream GNU descriptions.
>
> When such conflicts happen, we should give precedence to the GNU
> descriptions.
Oh, I see now. But should we really give precedence to the GNU
descriptions? For example, "guix lint libffcall" says that the proposed
description is "null (stale)".
Since we have our own conventions that are not necessarily coincide with
the upstream conventions, I believe it would be better to prefer our
synopses/descriptions instead.
And I think it would be good to adjust "guix lint" to avoid redundant
reports. For example, with the current (GNU) synopsis, "guix lint
hello" says:
… hello-2.10: synopsis should not start with the package name
With the modified synopsis, it would be:
… hello-2.10: proposed synopsis: "Hello, GNU world: An example GNU package"
So no matter what variant is preferable ('synopsis' or
'gnu-description'), we have a warning.
I see that it's not a trivial change as lint-checkers are independent.
Perhaps there may be added some priorities, so when a stronger linter is
passed successfully, then there is no need to check for weaker linters.
(Sorry if it's not appropriate, it's just a not-very-well-formed idea :-))
--
Alex
