On 05/11/2015 09:05 PM, Andy Grover wrote:
In an off-list email thread Jerome said:
Andy, on a semi-related topic (Christoph, now that you showed
interest I'll just keep you in the loop, tell me when you're bored
and I'll remove you ;-) ), my Debian maintainer put me down and I
need to host a repo for targetcli and do lots of packaging work.
This, among other things, includes a migration path (involving
transitional packages keeping lio-utils around to load legacy
configurations). I figured we could work on a common scenario that
would be similar to reduce the effort for RHEL/Fedora, to allow your
users to upgrade using the same principles. Of course this does not
solve the API changes, but moves us forward a bit. Also, what did you
ended up doing re. the name change so that we can install fb and
mainline in parallel for the transitional packages?
If you want to move forward on that last topic, we probably should
take that up on the ML in any case.
rtslib-fb is currently exported as "rtslib" and "rtslib_fb" (Python
imports cannot include '-') with a warning if the "rtslib" import is
used. Just changing the rtslib-fb packaging to remove the rtslib import
should allow parallel installation of original rtslib and rtslib_fb.
This was first done in the January 2015 rtslib-fb release, v2.1.fb52, so
I would hope any hypothetical direct users of python-rtslib on Fedora
have gotten the hint by now.
ok great. That should make the transitional packages for RHEL/Fedora
easier. The idea is to use a meta package that has both rtslib-fb and
rtslib/targetcli + some migration script used by the initscript. If
legacy config is detected, it is stared by the initscript, then dumped
in the new format. Then the user might uninstall rtslib-fb and the
transitional meta-package if he wishes so. When we detect a new format
config, we simply use it and do not attempt any conversion.
WDYT?
The same thing would be done for Debian repos, only using lio-utils for
2.x mainstream rtslib config conversion to the new format.
I'd like to share the logic for 2.x->3.x and -fb->3.x conversion, and
Debian imposes a constraint in that the services are always stopped on
uninstall and started on install (usually maintainers control that
behavior using an /etc/default/ script with a "start=yes|no" parameter
or something to that effect, sourced by the actual initscript). So there
is no way to actually have a service package upgrade run something
before the service is stopped prior to upgrade.
BTW I recently found out rtslib-fb is pkged for Debian as well:
https://github.com/agrover/rtslib-fb/issues/59
so its maintainer, Thomas Goirand (CC'd), would be someone else to keep
in the loop.
Good idea, will do.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
