-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2018-07-26 14:32, info at smallinnovations dot nl wrote: > It would help maintaining packages that depend on systemd too. You > only would have to add some code to use the libnosystemd instead > of libsystemd0.
If a libnosystemd package provides libsystemd, then there shouldn't be any additional code or checks necessary in existing programs. But both, replicating and changing "the libsystemd API" is wrong. libsystemd is really badly and monolithically designed. It's main problem is that it doesn't have an API, it has a lot of different APIs in a single library! This prevents providing packages with dynamic libraries replacing only one of the APIs. Therefore, ideally, the systemd developers should split the libsystemd libraries in smaller ones providing just one API per library. Something like libjournal for their logging API for example, instead of munching it together with everything else in libsystemd0. But I doubt that anyone of the systemd devs ever had that insight, I would even suspect they put everything in the same library on purpose, allegedly for simplicity, but in reality for better lockin. If a libnosystemd package is made, the different systemd APIs should be defined, then some library names, and finally it should do nothing more than forwarding the libsystemd function calls to the individual libraries for the different APIs if said library exists, and otherwise either do nothing or return an error depending on what would be worse. This way, it would be possible for different people to provide various implementations for different systemd APIs, without requiring them to implement all of them. Another problem could arise though, how stable are the systemd APIs? I once wrote https://git.devuan.org/devuan-packages/sd_journal_shim , it generates the libjournal library and just provides a subset of systemds logging functions so it can be used as a shim for those, even though it can't replace libsystemd. I think it's still in experimental, even though I'm not sure if it still works, because thankfully, noone seams to use the systemd journald APIs still, so noone seams to have had any need for this shim. Also, I think any such library should make it clear that it's existents doesn't justify libsystemd usage and discourage developers from using it. On 2018-07-26 16:17, Steve Litt wrote: > <rant> sysvinit and OpenRC typically have init scripts tens or > hundreds of lines, making init integration of an application seem > like an arcane art. What are they thinking? IMHO these immense and > unfathomable init scripts are what opened the door for systemd. > </rant> Those init scripts allow for any kind of scripting language to be used, and thus also allow for the usage of ones that look like unit scripts. I made an interpreter that allows yaml for declarative init scripts that could be used with sysvinit or openrc: https://github.com/Daniel-Abrecht/unitscript Daniel Abrecht -----BEGIN PGP SIGNATURE----- iQFIBAEBCAAyFiEEZT8xKpcJ1eXNKSM1cASjafdLVoEFAltaHIEUHG1lQGRhbmll bGFicmVjaHQuY2gACgkQcASjafdLVoGFbQgAsMfbIVyfKDj3Ze962oUrqSZoNFLR cTxcu73bUQxHuDVJhd9myXExBYtZgXtKLPMiCrIrOdKzwpGWNLkola7Fg2ggYQgJ jbWitQrpTgkUY3hrBdzkU8hBjKFkbMo7uXFGWbLa1q36gUyUwz44lX3HA8FM69Ax FYb4Cz6eLW7iDrWUtt3Ti5Ku4r8VY0nAgMNRP9U/fE5jrsVl5eSvtHkfOsfICMrR I13RtJ2evFkAty4HWicDrh3ejagLPP353jgRC7POjCaPdgEABd6CrHhIyYbJpkVS EYLl7ZJHaw171pKrQz6WRSTX/Xl/ybt+vv91Ia8TpHzgVKjsSDLGgORnQw== =Lc8K -----END PGP SIGNATURE----- _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
