Re: postrm::downgrade?
On Wed, Jul 02, 2003 at 03:18:36PM +0800, Niall Young wrote: I'm using a custom package pool for deploying software, but we need to cleanly rollback if an upgrade doesn't go as expected. In easy cases it is possible to first test a package with some testing machine and only put in in the used archive when it suites your needs. Agreed, I meant in *addition* to pre-deployment testing - say if testing didn't pick up all bugs and you discover fatal problems post deployment. How about a postrm::downgrade hook to reverse any changes made in the new version's preinst::upgrade so that when the old version's preinst::upgrade is applied you're not left with a potential mix of configuration? seamlessly - i.e. reverse all changes made in the upgrade. Is there another way? You'd need more than that. Apt would need to be changed to handle undoing of package splitting (Conflicts/Replaces), and is not always possible anyway, new packages, might use new file-formats which can be converted from the old-version but not back again. Yeah - it's a minefield of nightmares I know. Debian handles upgrades really well, but downgrades aren't as seamless. A postrm::downgrade hook is a pretty major change, it would take years to roll out - just wondering if anyone has thought about the problem before and if/when Debian could address this? A remove and clean install seems to be the only option which is unfortunate. Something to think about at least... Niall YoungChime Communications Pty Ltd [EMAIL PROTECTED]Level 6, 263 Adelaide Terrace Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000 donate to our Charity of the month which is the Eating Disorders Association of WA Inc. ... give a gold coin donation and I'll reward you with nice sweet chocolate! M -- Jodie Evans, Feb 2003
Re: postrm::downgrade?
On Mon, Jul 07, 2003 at 02:07:34PM +0800, Niall Young wrote: How about a postrm::downgrade hook to reverse any changes made in the new version's preinst::upgrade so that when the old version's preinst::upgrade is applied you're not left with a potential mix of configuration? seamlessly - i.e. reverse all changes made in the upgrade. Is there another way? You'd need more than that. Apt would need to be changed to handle undoing of package splitting (Conflicts/Replaces), and is not always possible anyway, new packages, might use new file-formats which can be converted from the old-version but not back again. Yeah - it's a minefield of nightmares I know. Debian handles upgrades really well, but downgrades aren't as seamless. A postrm::downgrade hook is a pretty major change, it would take years to roll out - just wondering if anyone has thought about the problem before and if/when Debian could address this? Never. This is not an effective use of developer time -- there are enough bugs with *upgrading* packages yet that we don't need to be worried about supporting downgrades. If you want individual maintainer scripts to support downgrading, dpkg already gives you everything you need: just compare the value of $2 with the current version to detect whether it's an upgrade or downgrade, and handle appropriately. But I'm not likely to accept patches for this on any of my packages, as I don't believe this is useful enough to justify the added complexity. -- Steve Langasek postmodern programmer pgpQ3pCcj3LdH.pgp Description: PGP signature
Re: postrm::downgrade?
* Niall Young [EMAIL PROTECTED] [030702 16:53]: I'm using a custom package pool for deploying software, but we need to cleanly rollback if an upgrade doesn't go as expected. In easy cases it is possible to first test a package with some testing machine and only put in in the used archive when it suites your needs. I've not yet seen a possibility when the only real way to test is to throw it directly in productive use. Removing the package entirely and reinstalling isn't an option, it needs to be done seamlessly - i.e. reverse all changes made in the upgrade. Is there another way? The main problem of supporting packages to redo things done in upgrade is in my eyes the inability for packages to do so in a proper way. The things I remember doing things in an upgrade are things like moving from /usr/X11R6/bin to /usr/bin and thus un- and reregistering the alternative-links and things like that. And they already often need many rereadings of the specification, looking which old versions did what and testing all the possibilities of updates from strange old-but-not-old-enough versions of it. Thus I deduce from Murphy's law that this will never work when you really need it. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: postrm::downgrade?
On Wed, Jul 02, 2003 at 03:18:36PM +0800, Niall Young wrote: I'm aware you can downgrade packages with `apt-get --force-yes install package=version-revision` but this doesn't seem to apply any postrm processing on the existing version of the package being replaced. How about a postrm::downgrade hook to reverse any changes made in the new version's preinst::upgrade so that when the old version's preinst::upgrade is applied you're not left with a potential mix of configuration? I'm using a custom package pool for deploying software, but we need to cleanly rollback if an upgrade doesn't go as expected. Removing the package entirely and reinstalling isn't an option, it needs to be done seamlessly - i.e. reverse all changes made in the upgrade. Is there another way? You'd need more than that. Apt would need to be changed to handle undoing of package splitting (Conflicts/Replaces), and is not always possible anyway, new packages, might use new file-formats which can be converted from the old-version but not back again. cu andreas
Re: postrm::downgrade?
On Wed, Jul 02, 2003 at 03:18:36PM +0800, Niall Young wrote: I'm aware you can downgrade packages with `apt-get --force-yes install package=version-revision` but this doesn't seem to apply any postrm processing on the existing version of the package being replaced. How about a postrm::downgrade hook to reverse any changes made in the new version's preinst::upgrade so that when the old version's preinst::upgrade is applied you're not left with a potential mix of configuration? I'm using a custom package pool for deploying software, but we need to cleanly rollback if an upgrade doesn't go as expected. Removing the package entirely and reinstalling isn't an option, it needs to be done seamlessly - i.e. reverse all changes made in the upgrade. Is there another way? I should point out that there are a number of changes which _cannot_ be rolled back. Upgrading a libdb database to a new format version is a good example. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpgBaVXGN71D.pgp Description: PGP signature
Re: postrm::downgrade?
On Wednesday 02 July 2003 08:18, Niall Young wrote: How about a postrm::downgrade hook to reverse any changes made in the new version's preinst::upgrade so that when the old version's preinst::upgrade is applied you're not left with a potential mix of configuration? It would be cool if: Dpkg could save backups of all config files when upgrading packages (probably in /var somewhere, so you get multiple versions backe dup and no .bak files everywhere). Also functionality to backup versions of configs so you could do: dpkg-saveconfig package-name --name=working_package_config Edit configs and make changes. Find you have made an error. dpkg-loadconfig package-name --name=working_package_config or perhaps dpkg-loadconfig package_name --rollback-to-last-version This could be extended to associate a configuration with a package version, and downgrading might involve: dpkg-loadconfig package_name --package-version=2.1.7-3 One of the better additions to newer versions of Windows is the ability to rollback configs to previous versions. Of course this is no use to you, but I thought it was an interesting idea. :-)
Re: postrm::downgrade?
Andreas Metzler wrote: possible anyway, new packages, might use new file-formats which can be converted from the old-version but not back again. Strictly speaking, any automatic conversion done during upgrades needs to be injective and thus (theoretically) reversible for being correct. Of course, that's only before the user changes the files generated during the upgrade. Cheers T. pgplJWLDDxIGK.pgp Description: PGP signature
