-----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

Reply via email to