Re: [DNG] automatic init script generation
On Fri, Oct 19, 2018 at 05:05:07PM +, zeitgeisteater wrote: > On 2018-10-17 11:29, Hendrik Boom wrote: > > On Tue, Oct 16, 2018 at 06:05:21PM +0200, Enrico Weigelt, metux IT consult > > wrote: > > > > > > I personally, got tired of inventing yet another init system - did that > > > over 20 years ago (actually, some things not so different from *early* > > > systemd - before they became totally nuts). > > > > > > The problem, IMHO, isn't so much creating an init system, but > > > maintaining the corresponding config/scripts for all the packages. > > > > > > One thing we perhaps could do is inventing a small declarative meta- > > > config language for certain common service types / usecases, so we > > > could automatically generate a large portion of the scripts/config > > > automatically for many init systems. > > > > As long as it doesn't metastatize into yet another thing like > > systemd unit files, incompatible with everything else. > > I realise that avoiding that is what you're proposing, but it's worth > > emphasizing. > > Systemd's unit files may well contain the information we need, but it's > > mot clear to me that their specification is stable enough for our > > purpose. > > > > I wonder if the right place to start is to write some kind of text > > processor that looks through existing init scripts lookinfg for > > similarity and difference, and then sorting out which differences are > > important and which similarities are copied bugs. > > > > -- hendrik > > > I'm looking at unitfile -> sysvinit conversion for a remaster project of mine. > The scope is narrow in my case, but I'm curious if it could scale enough to be > useful. Like... convert the bulk of standard service management and > automatically detect weird edge cases for manual review... (e.g. dumping them > to > file as "interesting, weird, please check me..."). It would likely be a net > gain > over trying to get raw manpower to handle every single package always. > > Maybe take this an inch at a time so it doesn't metastatize. Enough to be > useful > but no more (especially not enough to become its own stand-alone PITA). > > - ZE Looks like a practical way to go about it. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automatic init script generation
On 2018-10-17 11:29, Hendrik Boom wrote: > On Tue, Oct 16, 2018 at 06:05:21PM +0200, Enrico Weigelt, metux IT consult > wrote: > > > > I personally, got tired of inventing yet another init system - did that > > over 20 years ago (actually, some things not so different from *early* > > systemd - before they became totally nuts). > > > > The problem, IMHO, isn't so much creating an init system, but > > maintaining the corresponding config/scripts for all the packages. > > > > One thing we perhaps could do is inventing a small declarative meta- > > config language for certain common service types / usecases, so we > > could automatically generate a large portion of the scripts/config > > automatically for many init systems. > > As long as it doesn't metastatize into yet another thing like > systemd unit files, incompatible with everything else. > I realise that avoiding that is what you're proposing, but it's worth > emphasizing. > Systemd's unit files may well contain the information we need, but it's > mot clear to me that their specification is stable enough for our > purpose. > > I wonder if the right place to start is to write some kind of text > processor that looks through existing init scripts lookinfg for > similarity and difference, and then sorting out which differences are > important and which similarities are copied bugs. > > -- hendrik > I'm looking at unitfile -> sysvinit conversion for a remaster project of mine. The scope is narrow in my case, but I'm curious if it could scale enough to be useful. Like... convert the bulk of standard service management and automatically detect weird edge cases for manual review... (e.g. dumping them to file as "interesting, weird, please check me..."). It would likely be a net gain over trying to get raw manpower to handle every single package always. Maybe take this an inch at a time so it doesn't metastatize. Enough to be useful but no more (especially not enough to become its own stand-alone PITA). - ZE ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] automatic init script generation
On Tue, Oct 16, 2018 at 06:05:21PM +0200, Enrico Weigelt, metux IT consult wrote: > > I personally, got tired of inventing yet another init system - did that > over 20 years ago (actually, some things not so different from *early* > systemd - before they became totally nuts). > > The problem, IMHO, isn't so much creating an init system, but > maintaining the corresponding config/scripts for all the packages. > > One thing we perhaps could do is inventing a small declarative meta- > config language for certain common service types / usecases, so we > could automatically generate a large portion of the scripts/config > automatically for many init systems. As long as it doesn't metastatize into yet another thing like systemd unit files, incompatible with everything else. I realise that avoiding that is what you're proposing, but it's worth emphasizing. Systemd's unit files may well contain the information we need, but it's mot clear to me that their specification is stable enough for our purpose. I wonder if the right place to start is to write some kind of text processor that looks through existing init scripts lookinfg for similarity and difference, and then sorting out which differences are important and which similarities are copied bugs. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
