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