Re: CVS commit: pkgsrc

[Aleksej Saushev <asau%inbox.ru@localhost>]

John Marino <netbsd%marino.st@localhost> writes:

> On 4/9/2013 18:04, David Holland wrote:
>> Yes, well, it isn't done yet; when it is, I'd like to see the DESCRs
>> not gratuitously truncated.
>>
>>   >  rodent said he kept "most info", so what's the problem?
>>
>> Because someone (probably upstream) decided that they thought the
>> package should be described in a particular way; lopping off parts of
>> that to satisfy an arbitrary and fundamentally inane length limit at
>> best isn't a good idea.
>
> If it's longer than 24 lines because upstream can't keep it
> succinct, then the package maintainer can and should make it
> more concise.  The number 24 is not arbitrary, it's the standard
> number of rows on a console.  There's nothing "inane" about
> that.

The number "24" is exactly the arbitrary one.

First, the standard for as long as the recent decade is having scrolling
capabilities even in the modest consoles modes.

Second, were you more attentive to what actually happens than to pkglint
warnings you would note that with "no-scroll" requirement DESCR should
be much shorter because pkg_info output takes about twelve lines to
print package name, short comment, package requirements, project home
page, and so on. Thus the number "24" has no relation to the problem
of fitting pkg_info output to the number of lines on archaic console.

Third, if you personally don't like scrolling, you can use "pkg_info -c",
and thus DESCR is not meant for you. It is mostly for those users, who
browse generated HTML index on site or locally, or those who want to
understand why there're so many p5-Something-Something-Something
packages and what role they serve without guessing from concise comment.

> The original packager failed to follow the these guidelines, so
> fixing it now (however it's done) is legitimate.

Truncating them arbitrarily doesn't help anything.

>>   >  Long DESCR files are not a good thing.
>>
>> If any of them were>100 lines, then shortening them is probably a
>> good idea. Otherwise, what's the point?
>
> The point is some of us don't like using scroll lock to back up
> to see the description that unexpectedly scrolled off.  24 lines
> is generous; I'd personally limit it to 20.

How much time do you spend reading pkg_info output in archaic console mode?
How does that apply to other users?

>>   >  And now you are forcing me
>>   >  to agree with asau: If you aren't going to respect the pkglint
>>   >  rule, then remove it.
>>
>> There are so many things wrong with pkglint (or that it doesn't
>> understand) that treating its messages as anything stronger than
>> mild suggestions is extremely foolish.
>
> I can think of examples where that is true, but it also appears
> that people are quick to dismiss these guidelines with "pkglint
> is stupid" when it may not be deserved.  Pkglint can and should
> be a useful tool. These "wrong things" should be fixed and a
> priority put on getting pkgsrc tools in good shape.  pkglint
> isn't the only useful tool that suffers from neglect.

If you want pkglint to be useful tool, fix it then.


-- 
BECHA...
   CKOPO CE3OH...