[Fedora-packaging] Systemd scriptlet comments

[Toshio Kuratomi]

On Tue, Jul 26, 2011 at 09:57:48PM +0300, Ville Skyttä wrote:
> On 07/26/2011 08:41 PM, Ville Skyttä wrote:
> 
> > For now I've only thought about it more than a bit, and tested with
> > various modified versions of the vdradmin-am package.  I'll do some more
> > tests this week and document and publish the results.  Hopefully I'll
> > manage to get enough done because starting from next week I won't have
> > much time at all for that for a couple of weeks.
> 
> Before starting more work on this, does this test set sound as one that
> has enough coverage, and are there any differing opinions on the
> expected outcomes?  ("bootup state [not] saved" means whether it is
> written by systemd-sysv-convert in /var/lib/systemd/sysv-convert/database.)
> 
> 
> 1) pkg(sysv) -> pkg(systemd) upgrade
> 
> Expected outcome: sysv init script and symlinks removed, bootup state
> saved, service loaded from systemd unit, restarted if it was running.
> 
+1

> 
> 2) pkg(systemd) -> pkg(systemd) upgrade, no sysv stuff present
> 
> Expected outcome: smooth usual package upgrade (no unusual errors),
> bootup state not saved, service loaded from systemd unit, restarted if
> it was running.
> 
+1

> 
> 3) pkg(sysv) -> pkg(systemd) + pkg-sysv(sysv) upgrade
> 
> Expected outcome: sysv init script and possible symlinks installed,
> bootup state saved, service loaded from systemd unit, restarted if it
> was running.
> 
+1

This takes care of the default case of someone running Fedora with systemd.
It's the same result as #1 but checking that the scriptlets are not
negatively affected by the sysv init script package.

We do not need to test, for the purpose of these guidelines, whether the
symlinks are installed and whether the non-default case of Fedora running
a SysVinit works.  Those would be things that people who want to run
a sysvinit would need to work out and submit as a separate guideline for
their packaging.

> 
> 4) pkg(sysv) + pkg-sysv(sysv) (init script co-ownership) ->
> pkg(systemd) upgrade
> 
> Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed, sysv
> symlinks removed but init script in place, bootup state saved, service
> loaded from systemd unit, restarted if it was running.

I'd like to say this shouldn't be supported but I can see how we'd get into
this situation.  admin has pkg(sysv).  They install the *-sysv packages that
they're interested in using. Upgrade to the pkg(systemd) package.  The only
thing I see that could be changed in the outcome would be: *ideally* I think
that the sysv symlinks remain on the system but:

* I think that the current scriptlets don't do this
* I think that FPC's discussion was that the upgrade from pkg(sysv) to
  pkg(systemd) was a step that would lead to suboptimal consequences no
  matter what we did in the end [1]_

So I think that sysv symlinks being removed wouldn't be a blocker here.

(Brainstorming whether we could prevent the pkg(sysv) and pkg-sysv(sysv)
packages form being instaled together, I only see:
* *(sysv) packages conflict with old versions of the package
  Conflicting gets us back into the but-I-want-to-rev-the-old-version issue
  that we have with the current triggers. 
* *(sysv) packages require the newer version of the package
  Requiring doesn't work well for the case of some sort of
  systemv-initscripts package that has initscripts for a bunch of popular
  services.

So I guess we can't avoid this scenario)


I'm more interested in the following, similar scenario:

4b) pkg(systemd) + pkg-sysv(sysv) installed ->
  pkg(systemd) upgrade

Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed.  sysv symlink
untouched.  bootup state probably not saved.  service reloaded from systemd
unit, restarted if running

This would be a common scenario for an admin that's running a sysvinit
system under Fedora.

> 
> 5) pkg(systemd) -> pkg(systemd) upgrade while local non-packaged sysv
> init script installed
> 
> Expected outcome: all sysv stuff intact, bootup state not saved, service
> loaded from systemd unit, restarted if it was running.
>
+1

Hopefully 4b) and this one would either both work or both fail.
> 
> 6) pkg(systemd) initial install, no sysv stuff present
> 
> Expected outcome: bootup state not saved, service loaded from systemd
> unit, no errors.
> 
There's one caveat to this one which I'll explain right afterwards since
it's actually a global concern.

> 
> 7) pkg(systemd) initial install while local non-packaged sysv init
> script installed
> 
> Expected outcome: all sysv stuff intact, bootup state not saved, service
> loaded from systemd unit.

+1

So there's two global concerns.  The one I hinted at earlier is that each of
these tests needs to be run with the scriptlets for
service-allowed-to-start-on-boot and scriptlets for
service-not-allowed-to-start-on-boot.  In upgrade cases of systemd=>systemd,
the outcome should be the same.  In upgrade cases of sysv=>systemd and
initial install cases, the service should be enabled or disabled depending
on whether the service is allowed to start on boot or not.

The other one is that we have to check both that the service was (loaded from
the unit file/reloaded if running) and that it comes up appropriately (or
does not come up appropriately) after a reboot.

(The combinations of these are what makes testing time consuming)

.. [1]_: Note that this is mostly tied to Lennart convincing us that we
   could not migrate boot-up-state appropriately.  If migration of
   boot-up-state came back onto the table then we might have to reevaluate
   whether pkg(sysv) => pkg(systemd) could be smoothed in other areas.
   This is also the reason that we don't let people upgrade from sysv
   scripts to systemd scripts inside of a released Fedora and the
   prohibition would also be reevaluated if this were to change.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20110726/1c5a462e/attachment.bin