Re: package name change (moviemate -> mediamate)
On Wednesday 30 July 2003 15:56, Jamin W. Collins wrote:
>
> 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).
>
you should Conflict, Replace, and provide MovieMate. This will ensure a
smooth transition. You instead (may) want to upload a package called
moviemate which is a dummy package that depends on MediaMate.
Remember, if the user has MovieMate installed they will not get MediaMate
without actually asking for it.
> 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?
>
how much work is involved in hiding this from the user? In general you should
try to just make things work. The packaging details are something our users
should not need to know about. Remember from their perspective nothing
changed.
if you can scarf in the old db and make the upgrade just work, that is the
preferred approach. Of course that may prove to be too complicated or you
may just not have enough time.
Reply to: