IMHO i would expect package init scripts for default init system to be part
of a package (binary,base, etc) and scripts for alternate systems to be in
separate package(s).

Of course all residing in single src package maintained by the devuan
package maintainer.

Someone who decides to use alternate init is in some sense on his own, but
has all available scripts in packages so can install them.
Or the package for alternate init system can provide helper tools to
install available packages and even inform the user which packages have
missing scripts for selected alternate init system and have to be provided
manually.

So several init systems can coexist with one beeing more priviledged than
others.

Some enthusiast may even provide single package with all available optional
init scripts for all applications. Whatever suits.
Several options, one default with strict rules.

Regarding handling init scripts for different inits, the only hard moment i
can imagine is the time when devuan comes to decision to select new init
system as a default one.

But even then it will probably happen with a new release.
So all packages will be recreated including by default init scripts for new
system. And moving old sysvinit into separate, additional package, making
sysvinit optional.

--
Regards
piotr
written using my smartphone
03-05-2016 13:18, "KatolaZ" <katolaz@???> napisał(a):

> On Tue, May 03, 2016 at 12:18:37PM +0200, parazyd wrote:
> > On Tue, 03 May 2016, KatolaZ wrote:
> >
>
> [cut]
>
> > > Why we don't just ship the init scripts for each system with the
> > > corresponding service, install them "somewhere else" (e.g.,
> > > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been
> > > already suggested by others) and then copy (or symlink) the
> > > corresponding directory in /etc/ only when the user selects "wtf" as
> > > init system? This could be managed much more easily by
> > > update-alternatives, which has just to update two symlinks, e.g. he
> > > one corresponding to /sbin/init and the one corresponding to it's
> > > bloody scripts directory...
> >
> > This is very much a hack. Not really a good way to do it. As Dan says,
> > submitting patches to the already existing packages is a much more
> > elegant way. I think Dan proposed a very good thing, almost a complete
> > solution.
> >
>
> I am not against submitting patches to existing packags to include
> init scripts.
>
> Only, whatever smart solution you come up with guys, please try as
> hard as possible to keep it as *simple* as possible, not a single bit
> more, not a single bit less. The fewer interactions we have among sets
> of init scripts belonging to different init systems (ideally, no
> interaction whatsoever), the easier maintaining them in the long run,
> and plugging in new init systems as yet unforeseen.
>
> Ideally, switching between init systems (e.g., reverting back to an
> init system which is known to work) should be achievable from a
> single-user root shell spawned as an emergency "init", using only a
> few executables in /bin and /sbin. Anything more complicated than that
> risks to become not that useful or even harmful in the long run, IMHO.
>
> PrimoDevuanStabilisCreandaEst
>
> KatolaZ
>
> --
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>