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 original packager failed to follow the these guidelines, so fixing it now (however it's done) is legitimate.
> 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.
> 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.
That said, this particular rule is logical to me. There's no good reason to have a description longer than suggested (and verbatim copying of upstream propaganda isn't a good reason either).