Hi, After lots and lots of requests, I went through and changed all the tool names in oggz so that they contain hyphens: http://trac.annodex.net/changeset/3627 That patch touches the names of built executables, references to them in docs and scripts (ie. oggz-dump is called by oggz-diff) etc. There's lots of little places where the tool names appear, so please test against the current oggz svn to check for breakage :-) 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] * On 'make install', forcibly remove the old binaries if they are present * On 'make uninstall', forcibly remove the old binaries if they are present * 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 Thoughts? Conrad.
> 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 presentI'd say do this in 2 releases time.> * On 'make uninstall', forcibly remove the old binaries if they are presentWouldn'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 itI 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/
2008/7/16 John Ferlito <johnf at inodes.org>:>> 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.Ok, in changeset:3776 (http://trac.annodex.net/changeset/3776), I've made it so that 'make install' will add symlinks for deprecated tool names, but only if they are already installed; and 'make uninstall' will remove each deprecated tool -- but only if it is a symlink, to keep to the policy of only uninstalling what we installed. thanks for the feedback John, and others that discussed this over irc or beer. The Makefile rules I used just call "rm" and "ln -s" directly. Does anyone have advice about how to make this portable, ie. is it ok to just write $(RM) and $(LN_S), after calling AC_PROG_RM and AC_PROG_LN_S in configure.ac, or would that make configure fail if those programs aren't installed in the first place? please test :-) Conrad.