[ogg-dev] oggz tool renames

[John Ferlito]

> Now there's the minor problem of upgrading from an earlier version of
> oggz, and having both versions of the
> tools around (eg. having an old oggzdump lying around even as
> oggz-dump is upgraded). What are your thoughts about ways to deal with
> this? eg.
> 
>  * On 'make install', replace the existing executables [if present]
> with symlinks to the new ones. ie. Replace oggzdump with a symlink to
> oggz-dump [if and only if oggzdump exists]

I like this as it won't break any scripts.

>  * On 'make install', forcibly remove the old binaries if they are present
I'd say do this in 2 releases time.

>  * On 'make uninstall', forcibly remove the old binaries if they are present
Wouldn't bother here. Since make uninstall is rarely used and it
should only deal with uninstalling what it installed.
> 
>  * On 'make uninstall-old-cruft', forcibly remove the old binaries if
> they are present
> 
>  * Do nothing, but document that people should explicitly "make
> uninstall" in the old version before installing the new one; or
> (similarly) that it's a packaging problem, and distro maintainers
> should deal with it

I don't like the nothing approach since then people will have two lots
of binaries on their system which is just going to cause confusion.

For the debian packages I'll be providing symlinks along with a
warning at install that the binary names have changes and symlinks
will be deprecated in future version

Another idea could be that in the next release you make symlinks. The
release after that turn the symlinks into scripts which print a
deprecation warning and then run the old binary. In the release after
that remove the symlinks.

-- 
John
http://www.inodes.org/