Re: [Fink-devel] scipy-core-py name change

On Sun, Sep 27, 2009 at 05:10:36PM +0200, S?bastien Maret wrote:
> Hello,
> 
> For about 6 months at the end of 2005, the numpy package was called  
> scipy core. That's the name we picked up for the fink package when  
> numpy/scipy-core was first packaged. In order to avoid confusing users  
> any longer, I'd like to rename the scipy-core-py package to numpy-py.  
> For this I propose the following path:
> 
> 1 - Revise scipy-core-py (1.3.0-4) so that its depends on fink- 
> obsolete-packages and that it conflicts/replaces numpy-py (>= 1.3.0-4)
> 
> 2 - Create a numpy-py package (1.3.0-4) based on scipy-core-py and  
> that conflicts/replaces scipy-core-py

That's a deadlock even if (per step 3) you fix all .info at once: user
tries to update package1 (that brings NEW_NAME, which forces out
OLD_NAME) if he has a package2 installed and not updated (prevents
removal of OLD_NAME). Fink doesn't understand the idea of "these all
must be installed in a single 'dpkg -i'". I don't think you even need
to force *swapping* them if you just want a seemless upgrade from one
to the other for the name-change.

The usual "rename a package" magic is:

1. Revise OLD_NAME (at NEW_VERSION) do that it is a type:bundle (no
"real" package contents) that depends on fink-obsolete-pacakges and on
NEW_NAME (>= NEW_VERSION).

2. Create NEW_NAME (at NEW_VERSION) that replaces OLD_NAME (<<
NEW_VERSION).

That way, the new package (and anything updated to use it) can be
installed without forcing out the old (so unupdated things don't break
deps) and upgrading an installed old automatically brings the new
name (so unupdated packages get the new package too). That makes:

> 3 - Modify all packages that depends on scipy-core-py that they depend  
> on numpy-py (>= 1.3.0-4) and bump all revision numbers. All the  
> packages will need to be modified at the same time to avoid breakages.  

not required. Maintainers can do so when they get around to it (avoid
rev-up/rebuild just for this tweak) with no functional harm in waiting
until a more substantive reason to update. Users may get a warning
about the obsolete, but it's only a warning because there's no
functional problem.


-- 
Daniel Macks
[email protected]
http://www.netspace.org/~dmacks


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf