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