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
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
