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