[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: pkgsrc
John Marino <dragonflybsd%marino.st@localhost> writes:
> On 4/10/2013 19:17, Aleksej Saushev wrote:
>> John Marino<netbsd%marino.st@localhost> writes:
>> 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.
> Having the ability to scroll doesn't justify the existence
> unnecessarily verbose descriptions.
If you want concise description, you use "pkg_info -c".
>> 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.
> That's a good point. I will happily support a shorter limit.
> However, I was talking about "> cat DESCR" so my 24-line comment
> is perfectly valid. We're talking about command-line use,
> remember? pkg_info doesn't help for packages that aren't yet
You can use "less DESCR" with better success. Thus what you're arguing for
is your personal preference to continue using broken way to view textual files.
>> 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.
> I disagree. Greg Troxel already addressed this well. There's
> no justification for anything longer than the equivalent of an
> abstract. It doesn't matter if it appears in a browser or xterm.
>>> 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.
> There is nothing "arbitrary" about creating a concise summary.
> I realize that the description is in English and that for many
> developers English is not their native language. However, a 10
> year-old has the ability to summarize a topic in a few
> sentences. I didn't see the commits, but rodent indicated his
> editing was not arbitrary. "kept most info" implies an
> intentional process.
I think that you don't actually have any idea of what you're talking about.
How long has it been since you got good summary from a teenager?
How many teenagers have you worked with?
The fundamental difference between us is that I have seen those commits.
I reviewed changes and found that in some cases they caused loss of
In fact, after this acknowledgment that you have not actually looked
at changes you should stop further discussion. You have no idea what
reduction of "verbosity" you're talking about now, and it doesn't make
any good impression of you.
>> How much time do you spend reading pkg_info output in archaic console mode?
>> How does that apply to other users?
> 1. I don't use pkg_info, I use (more|less|cat). 2, I spend all
> my time in console mode. 3, console mode is lowest common
> denominator, it's reasonable to assume this is what is targeted,
> not a browser.
Some modern LED displays as well as punch cards have only one line.
If you use "more" or "less" then you don't have any of issues you're
talking about. Thus your wish to truncate information at any price
to make it fit screen size is not justified by practical need actually.
>> If you want pkglint to be useful tool, fix it then.
> Part of your issue is that you don't respect standards. For
> example, technically there is nothing wrong with the unit of
> inches. If you produced a blueprint in inches, and a scanner
> flagged it and said, "imperial units detected, switch to SI
> units", you'd respond the scanner was stupid and imperial units
> are perfectly legitimate to use. Well, that's true, but you
> aren't respecting a declared standard. So I can project that
> it doesn't matter how improved the pkglint tool is made, you
> probably wouldn't pay attention to it anyway. Am I way off?
It is not me who is defending obsolete "standards" and
What is more important is that I don't use false analogies,
don't build straw man, and don't appeal to past time here.
Main Index |
Thread Index |