[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

package name change (moviemate -> mediamate)



What is the preferred method of effecting a package rename and upgrade
between versions?

Movie Mate v0.9.2 is currently in the Debian archive.  Due to upstream
changes (added tracking for other media types), the name has been
changed to Media Mate.

Thus, Media Mate is the upgrade to Movie Mate.  This leaves me with the
question of how to properly change the package name and upgrade
installations of the older package.

In building the new Media Mate package, I've declared a Conflicts with
the moviemate package to effect moviemate's uninstall when the mediamate
package is installed.  However, this leaves the question of migrating
the moviemate's configuration to mediamate.  For this, I pull the
debconf answers for moviemate's questions and set them as the answers to
mediamate's questions (which are mostly the same), and set the _seen_
flag to true so the questions will not be asked (much like an upgrade
where the package name has not changed).

Since the package name has changed, the configuration and data files are
now stored in different locations.  So, I plan on moving the data files
to their new location.  But, what about the old configuration files, and
the old package's state in dpkg?  Should these be removed since the new
package is installed (more or less an upgrade) or should these be left
because the old package hasn't been purged and the new one has a
different name?  Also, moviemate has asks a question during install
about removing the DB on purge, with the answer stored in debconf's db.
During the upgrade would it be acceptable to clear this answer under
moviemate once it's been migrated to mediamate since the old DB is
upgraded and used by mediamate and a purge of moviemate would then
remove a database that's still in use?  Or, should mediamate copy the
old database and and leave it for moviemate to potentially purge?

Personally, I'm leaning toward having the new package manually remove
all the old packages configuration files and unsetting the DB purge
flag.  But, I can see how this may be seen as a bad thing.  Thus, I
figured I'd ask here for comments and suggestions on how to handle this
type of situation.

-- 
Jamin W. Collins

This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar



Reply to: