Damien Raude-Morvan <[email protected]> writes: > Olivier, > > On 04/06/2012 16:52, Olivier Berger wrote: >> Damien Raude-Morvan <[email protected]> writes: >>> I would expect that users would read upstream upgrade guide before >>> upgrading : >>> http://opennebula.org/documentation:rel3.4:upgrade >>> >> >> I'm afraid this isn't a valid expectation for a Debian >> maintainer. > > For a critical software like OpenNebula, I would expect user to at least > (1) do a test upgrade before upgrade of controller node and (2) read > upstream upgrade guide... but maybe I have too much expectation to > debian users. >
The problem is that once you started the apt upgrade, you get stuck, and only chance to start over is to first reinstall the previous version from snapshots, destroy VMs, upgrade, start over VM deployment, etc. If an APT upgrade can't do everything, it shouldn't let the user stuck, without a way back, and refuse the auto upgrade in the first place. There are plenty of 'critical software' in Debian, for which auto upgrades aren't possible, but which will help the user proceed to manual changes at least. Maybe there should be a versioning on the opennebula-node package that prevents auto upgrades in case of such incompatibilities, like opennebula-node-2.2, opennebula-node-3.2, opennebula-3.4, mutually excluding themselves, forcing the admin to read the upgrade docs ? I've seen something similar for postgres, where the DBs will beed to be manually exported and imported in the next version IIRC. >> At least, there should be a NEWS big red warning IMHO. > > I will had something to NEWS entry, but as you know it's not binding for > users (someone who haven't apt-listchanges installed for instance). > Then I think there can be a preinst debconf template message in last resort. >>> Before installing OpenNebula 3.4, make sure you don't have >>> any active VMs. Shutdown or delete all VMs. >>> >>> Ii will be difficult on the long run to keep maintaining all tricks to >>> keep package in sync with upstream handling... >>> >> >> That's the fate of the Debian maintainer : never pretended it would be >> easy. >> >> Anyway, for the problem at stake, I guess there could be some kind of a >> check in a script that uses onevm list to check the status for instance >> (or some lower level API I'm not aware of). > > Would you provide a patch ? :) > Nice one ;) When I'm done with other stuff, who knows, but for the moment I still have to spam^Wtest and report on FusionForge packaging in higher priority. Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
