One more thought...
I think the Debian way would be to have a transition package containing
lio-utils, and modify the initscript to account for it.
The initscript would check on first start if we are in an upgrade
scenario (no new config, an old lio-utils config present), invoke the
transition lio-utils code to start the targets and then dump the config
in the new format.
But that would involve keeping around the lio-utils code just for that
one-shot usage... And I hate the idea of having a dependency on it just
for that.
WDYT?
On 10/05/2014 10:30 AM, Jerome Martin wrote:
On 10/05/2014 09:37 AM, Ritesh Raj Sarraf wrote:
Thanks for the bug report.
Jerome: How can we ensure to have the old 2.x settings / targets in 3.x ?
Manually, this is easy.
But to automate package upgrade is bit of a brain-twister.
I haven't found yet a good way to do it.
Basically, the config format is completely different, so we need to
start the new initscript and save the config (in the new version) while
the target is running. But removing the previous package actually stops
it...
And there is no way to reload the old config after the upgrade because
that depends on lio-utils, which we want to get rid of...
We would need a way to tell the upgrade process NOT to stop the 2.x
target service when removing the old package, but I did not find a way
to do that.
Any idea ?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
