On Tue, Jun 12, 2007 at 05:29:03PM -0400, Kevin Horton wrote:
> I intend to take over bluefish, which has been released by the  
> previous maintainer.  This package currently has three variants:
> 
> bluefish
> bluefish-gnome2       # with gnome2, with vfs enabled
> bluefish-gnomevfs2  # with gnome2, but with vfs disabled
> 
> I find the last variant name (bluefish-gnomevfs2) inconsistent with  
> the fact that vfs is disabled.  I would like to change the name of  
> this variant to "bluefish-gnome2-novfs".  I believe that this would  
> improve clarity.
> 
> I need advice on the best way to handle the transition from the  
> current variant name structure to the new one.  Anyone who has  
> bluefish-gnomevfs2-1.0.6 should be automatically upgraded to bluefish- 
> gnome-novfs2-1.0.7.  At first glance, this looks like a job for  
> Replaces/Conflicts, but I do not understand how I would do this for  
> only one variant.  The package currently has Replaces/Conflicts on  
> all variants:
> 
> Replaces: bluefish, bluefish-gnome2, bluefish-gnomevfs2
> Conflicts: bluefish, bluefish-gnome2, bluefish-gnomevfs2

Here's an idea (untested, so verbose with goals in case it doesn't
work quite as I write it:)

Adjust the .info to use the new-named variant in its Type field
*instead of* the old-named one. Put the new-named one in Replaces and
Conflicts, remove the old-named one from Conflicts (leave it in
replaces). Rev-up. If user has nothing installed, this new set of
"real" variants works as usual. If user had old-named installed, these
could overwrite it as well.

Create an external .info for just the old-named package, at the same
Version and Revision (i.e., revved-up) as your existing .info. No
Conflicts or Replaces. Have it Depends on the new-named package at >=
%v-%r and also Depends on fink-obsolete-packages, as (among the other
usual fields):

Source: none
CompileScript: #
InstallScript: <<
  mkdir -p %i/share/doc/installed-packages
  touch %i/share/doc/installed-packages/%n
<<

This is the dummy upgrade package. If user had old-name real package
installed, this higher-revision of it would get installed and bring in
the real new-named package. None of the real packages Conflicts with
this upgrade package (which doesn't have the real files in it), so
both it and any one real one can co-exist.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to