Daniel,
I am quite willing to convert my packages like
sparky-py, pymol-py and relax-py over to use update-alternatives
to create the required non-variant symlinks. However I still think
not conflicting the different python variants for python based
applications is of extremely dubious utility. While it makes
perfect sense to have python variants co-exist for python
support libraries or frameworks, the rational for doing the same
for python applications is far less clear. If the applications
packaged are so buggy that the user must switch between different
python variants of them constantly that issue should be addressed
with the upstream developers. On the other hand, allowing python
variants of python applications to co-exist only makes it more
difficult for the user to automatically purge unneeded python
variants of those applications when he updates to a new python
variant. For example, say a user has been using the py25 variants
and later decides to switch to py26 ones, why should...
fink install sparky-py26
...not assist them by removing the older python variant.
I have felt for some time that this 'feature' of allowing
python applications to have co-existing variants will only
end up wasting disk space on users hard drive by leaving
unnecessary packages behind during upgrades.
Jack
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
