On Wed, 27 Nov 2019 20:35:42 -0600
goli...@devuan.org wrote:
> Even though I agree that we should never have been forced to reinvent
> a wheel that wasn't broken, I have no problem with co-existence. But
> the systemd cabal might not want to share. Will be interesting to see
> if at some point those unit files are locked down in a way that
> prevents the conversion.
Binary files :-)
I wrote a smiley, but their logs are binary and their architecture is
more bizarre and pathological than binary logs. So yeah, they might.
> Then back to the creative drawing board.
I examined the source for 5 minutes. The main routine is:
=====================================
# parse command line
while getopts i:n: opt
do
case $opt in
i) instance=$OPTARG;;
n) name=$OPTARG;;
?) printf "Usage: %s [-i instance] [-n servicename] [filename]\n"
"$0" exit 2;;
esac
done
: ${instance=INSTANCE_NAME}
shift $(($OPTIND - 1))
# convert unit file
read_unit "${1:--}" "$instance"
write_init "${name-$inifile_unit_name}" "$instance"
=====================================
Most of the complexity is in the write_unit() function, which is needed
only for sysvinit scripts (if I read things correctly). I'm pretty sure
that if one comments on the write_unit() line, and maybe adds five or
ten lines to output the output of read_unit(), the unit file is no
longer needed, and each init can use the output of the modified
shellscript to create its startup scripts, confs and dirs.
Once all those intermediate files exist, people can, at the peoples'
leisure, convert those intermediate files to the startup facilities of
their choice. So you were right the first time: This is a BFD, and it's
good.
> One
> possible scenario . . . if init freedom can survive long enough,
> systemd might just trip over its own feet and go poof.
Or perhaps IBM will get sick of this schtick and make Redhat dump
systemd. Write IBM's CEO.
> Hey, I can
> dream . . . :D
A lot of Martin Luther King's dreams have come true.
SteveT
Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
