Am 14.04.2011 um 14:33 schrieb Martin Costabel:

> Max Horn wrote:
> []
>> Though I still agree that sometimes it's a bit tough to avoid the
>> package name... OK, I can't think of a concrete example right now, but
>> imagine you had a tool called "image" for "image processing"... using
>> the description "process" alone seems a bit too minimalistic. So in the
>> past I tried to come up with synonyms ("picture processing" maybe?) but
>> this can be a bit artificial at times.
> 
> I have an example: The package "lie" has as its description on its web 
> page "Computer algebra package for Lie group computations", which is 
> both too long and contains %n.

Great example (and, cool to learn that we have a lie package -- I gotta tell 
Arjeh Cohen about that when I see him next ;).

> 
> I am all in favor of removing that rule from the validator.

OK... anybody opposed? To summarize, this are the changes I propose, each 
should be trivial to implement:

1) Drop the _warning_ when a package description exceeds 45 chars, only keep in 
the 60 chars _error_
2) Allow package name to be used in description.

Alternatively, we could keep these warnings, but make them non-fatal in 
maintainer mode. This could be done by making it less "binary": Instead of 
$looks_good equal to 0 or 1 (bad or good), we could distinguish between three 
levels "perfect", "warnings", "errors". 

Anyway, I still think we should drop at least the 45 warning completely. It's 
just outdated, back from the days when screens were small ;).


Bye,
Max
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to