After a brief discussion with dmacks on IRC, let me clarify some points: My proposal is to change the description of obsolete packages to the following *when it makes sense* and isn't too long: Description: OBSOLETE use package 'FOO' instead
Some remarks: * Of course there are cases where this is not suitable. E.g. "FOO" might be very long. Or there might be multiple possible replacements for the package, not just a single one. In such cases, I think we should use something like Description: OBSOLETE see full description for details or maybe Description: OBSOLETE use 'fink info %n' for details And then provide a detailed explanation in DescDetail. The second proposed text is easier to understand for beginners, but might be problematic if %n is very long. In any case, I recommend that we deal with such cases as we encounter them, on a one-by-one basis. * Should we put a colon after OBSOLETE or not? In my proposal I don't, following the majority of obsolete packages out there. IMHO it is superfluous, and just makes the desc field content longer. But I don't feel strongly on this and will be happy either way * Many packages out there use Description: OBSOLETE use FOO instead but I specifically inserted the word "package" and the '' around the package name to avoid confusion. In many cases, it is clear from context that a package is meant, but not always, so I figured this would help the user * Do we rev up the affected packages or not? By our policy, we really should. For many of the affected packages, it doesn't matter, as they are only bundle / nosource packages and tiny. But some obsolete packages are splitoffs (e.g. xchat-ssl is obsolete and a splitoff). In these cases, a rev-up forces users to rebuild an otherwise fine existing package. My view: I would prefer to follow the policy and rev up packages; if a user still has them installed, this way they explicitly see that they are about to update an obsolete package (something they may have missed in the past due to a confusing description text). If there are any truly big packages with an obsolete splitoff, we could either make an exception for that, or just wait with releasing the desc fix until there is a natural update coming anyway. That's it. Considering that this is a pretty small and marginal thing, compared to much more important things like a transition to git for everything (which I still would love to see!) So, I don't think we should spend much time discussing this anyway. So far, I got one positive feedback (by dmacks), and zero negative / neutral, so unless I hear complaints soon, I'll start to implement this (manually, not with a script, to ensure I don't miss problematic cases). If you would like to take care of your packages yourself (e.g. to fix other stuff in them while you are at it), please let me know. I'll start the conversion with unmaintained packages and my own anyway, then proceed to isolate ones, and will keep the splitoff ones (except for my own) till the end. Cheers, Max ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ 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
