On Tue, 3 May 2016 09:59:40 +0100 KatolaZ <kato...@freaknet.org> wrote:
> On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote: > > [cut] > > > > > This can all be handled in each package with the package triggers > > enabled easily with a debhelper script similar to dh-systemd which > > makes it easy to deploy init scripts/unit files/runscripts etc in > > their own namespace and /etc/<init-system> and only deploy them > > when the init system is installed and removes them when it is > > removed. This shifts the burden to package maintainers, but that > > is the right place for them and we can make it easy to add > > additional init-scripts by filing bugs with patches. > > But do we really need all that complication? Couldn't we just leave > the initscript of each init system in a different directory and *tell > the init system* where they are to be found? This will allow a much > easier coexistence of different confs. As you read my response, please keep in mind my biases. I tend to break away from the package manager at the first hint of trouble... If katolaz was saying "hey, it doesn't have to be that difficult", then I agree with him. Having installed Runit, s6, and Epoch direct from upstream developer source code, I find that the upstream developers had the best ideas about where to put which kinds of files. To the extent that the Devuan package conforms to what the init's developer used, you KNOW where its files go. I see one instance in which Devuan should depart from upstream ideas, and that's in situations where the init's developer saw fit to create a new directory off of the root, such as /service in daemontools. Changing that to /var/service isn't difficult at all. Anyway, including extra inits needn't be a big effort (except for creating runscripts/EpochConfigs: the original developers pretty much got everything right. SteveT Steve Litt April 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng