Am 14.04.2011 um 03:30 schrieb Daniel Macks:

[...]

> Would be easy to make validator relax its Description test for obsolete 
> packages (there are already other special allowances for them that are 
> fatal otherwise).

That would be good then. Though actually, I wonder if we should relax the 
length limitation a bit, too. 45 chars is *very* tight, and the original 
motivation came from avoiding cut-off descriptions when doing a "fink list" in 
a narrow terminal window. But maybe it's time to relax that a bit, to say 60 
chars ?

I just run a "fink --quiet check" on all our .info files, and I got a lot of 
warnings -- about 90% of them about the 45 chars limit. Not helpful...



> The rationale for the normal "No %n in Description" 
> rule is that Description is always displayed in the vicinity (and often 
> the very next string word after) %n: "lzma LZMA file compressor" seems 
> pretty silly. We already know it's called lzma, just need a phrase that 
> describes WTF that is. "Command-line file-compression tool" says even 
> more (and more useful) info. 

Exactly, that's why we added in that rule originally.
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.

So, maybe we should warn about this, but not make it fatal in maintainer mode? 
Or maybe we should have maintainer mode and strict maintainer mode? Or if 
maintainer mode detects an errors, instead of bailing out, ask the user whether 
to continue anyway [y/n] ? 
This way, you can at least get the other -m enabled tests, without being forced 
to first deal with pesky and not so important description wrangling. 


>  
> Max (or whoever decides what pattern has consensus as a best-practice), 
> please update the fink-wiki page (see 'fink info 
> fink-obsolete-packages'). 
>  

Done. Though we should discuss my proposal on what to do if there is *not* a 
clear successor. I suggested this on the Wiki:
  Description: OBSOLETE use 'fink info %n' to learn more
But maybe you guys want something else, e.g.
  Description: OBSOLETE use 'fink info' to learn more
or whatever. 


Some more random ideas:

Should we add an "obsolete" dir / category (besides "net", "devel", "crypto" 
etc) where to move obsolete files?

Should we require obsolete packages to have an explicit Distribution list ? I 
mean, there is no point carrying all these packages over to 10.7, or is there?

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