Hi,
From my perspective, it would be nice to keep the old tcm_node and lio_node
tools around. I know that they are deprecated but there are a lot of tools
around that rely on them.
The migration from the lio-utils to targetcli startup scripts could possibly be
done by removing the init script from lio-utils and replacing it with the one
in targetcli. You would need a NEWS and/or a high priority debconf notification
to ensure people are aware of the change, and possibly leave saving the current
configuration to the user even.
Certainly stopping the target when removing lio-utils seems very wrong indeed,
especially as there isn’t a daemon involved. I’ve always thought the lio-utils
{pre,post}{inst,rm} scripts shouldn’t attempt to run the init scripts at all.
So here is what I think:
1. A new version of lio-utils with:
a) the init script removed
b) Recommends: targetcli >= [new version]
c) a NEWS.Debian entry and/or debconf prompt about transitioning to targetcli
2. A new version of targetcli/rtslib with:
a) 'dh_installinit --no-start’ to not break running targets
b) Breaks: lio-utils << [new version]
c) Replaces: lio-utils << [new version]
d) a NEWS.Debian entry and/or debconf prompt about transitioning to targetcli
e) the other bugs fixed that make them unusable...
That way, in theory, one gets the new de-fanged version of lio-utils during the
upgrade which keeps the current targets running. The new targetcli comes along,
and can either write out its own config based on the running targets or the
user can be prompted to do so.
HTH,
Chris
> On 5 Oct 2014, at 09:35, Jerome Martin <j...@netiant.com> wrote:
>
> 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-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
