TBH I personally think clever conditional logic in the package install for
if (systemd installed) { systemd scripts, sysvinit scripts get
diverted to /dev/null }
elsif (sysvinit for real) { install sysvinit scripts, divert systemd
scripts to /dev/null }
else { print that you're doing neither of the above b/c the world is
confusing }
would be my default idea, but that seems like a lot of moving parts
where just breaking things out has many fewer things to go wrong, and
has precedent in fanning out into e.g. zfs-initramfs, zfs-test,
zfs-zed...
Also, while I support the idea of permitting sysvinit scripts to be
used for some users, I think "just" adding a Conflicts: systemd-sysv
anywhere but in an optional part of the packaging would be a drastic
user experience problem - they'd just get a sudden prompt to rip out
part of their system (a part that popcon suggests over 50% have
installed, and 42% have used parts of recently, in the case of
insserv) on trying to upgrade a minor version.
- Rich
On Tue, Jan 1, 2019 at 2:22 PM Richard Laager <rlaa...@wiktel.com> wrote:
>
> On 12/31/18 6:34 PM, Rich wrote:
> > It seems like what we might want is an OR dependency on two child
> > zfs-{systemd,sysvinit} packages - and for those two packages to
> > conflict with each other (and require the appropriate respective init
> > packages)?
>
> I don't think that's desirable. If this is actually required, then
> wouldn't every package trying to support systemd and sysvinit need to do
> that same? That would be a lot of work. No other packages are doing
> this; there should be some other solution.
>
> If systemd-sysv and insserv are not co-installable, that conflict should
> be expressed in those packages.
>
> --
> Richard
