-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/6/11 7:19 AM, Max Horn wrote: > 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
Sounds good to me. I've got one thing to add: when an obsolete placeholder package is a Splitoff of a current real package, that brings in an indirect dependency upon fink-obsolete-packages to the current package, and users find that confusing. Since the obsolete placeholder presumably isn't going to need much in the way of updating, I have found that it's not much of a maintenance issue to give such packages their own .info files. - -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2cXAAACgkQB8UpO3rKjQ8qrQCfe6Rm0kgbdc58n2xT/5eQ6CGt Zu8AoJ+4dVPej+lpuwUCjyH8zsh4MKLq =L+m0 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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