(Here's another one I may later wind up regretting; I'm out on too many if-I-remember and if-I-understand limbs, and am thus speaking based on too many possibly-false premises, and I'm also now explaining personal preferences which might readily be deemed too minor or too niche to be reasonable to bother supporting. I don't want to just drop the conversation midstream at this point, however.) On 2020-01-03 at 14:36, Russ Allbery wrote: > The Wanderer <wanderer@fastmail.fm> writes: > >> On 2020-01-03 at 13:35, Russ Allbery wrote: >>> Why would that be necessary? > >> Which part? The splitting out, or the accepting of the init >> scripts? > > Both. > >> The splitting out I think I've already addressed, if not directly >> or at length; I can go over it more specifically if desired, >> although I sometimes have a hard time phrasing things in that >> context in ways which aren't unintentionally provocative. The short >> version would be: to avoid undesirable side effects from other >> parts of the systemd package. (Again, it's been long enough that I >> forget what those side effects were, although I think they had to >> do with logind.) > > So far as I can tell, installing the systemd package by itself > shouldn't do anything. It's possible that I'm wrong, but if so, it > might be easier to just fix that problem rather than splitting out > binaries. It's also possible that you ran into some long-ago-fixed > bug and there is no longer any problem with installing the systemd > package on a system that isn't running systemd. If I recall and understand correctly, installing systemd-the-package will result in at least some of the daemons therein - including both systemd itself, and systemd-logind - being set up to run automatically in the correct contexts (whether by scripted invocation set up by a package, or by socket activation, or by some other means), in such a way that they will generally wind up running even on a computer where systemd-the-daemon is not the init system. I'm currently digging through the result of 'apt-get source systemd', and I haven't yet managed to either confirm or refute this with certainty. If that's not true - if having that package installed will (now) never lead those daemons to be run without something external to the package which triggers them to get run, and a non-systemd-as-init-system machine will (now) not involve anything which triggers running them unless the sysadmin specifically sets it up that way - then I'm on entirely the wrong track here, and unless there's something else I'm not remembering, my split-the-package objections almost certainly disappear. (Although it would probably then become harder to ensure that I don't install something which is going to trigger running any of them.) Again if I recall correctly, there were some behaviors which arose from having logind running in a non-systemd-as-init-system environment which the maintainers did not consider something which they would need to fix but which I found undesirable. Unfortunately, I have largely forgotten what they were; I have a vague memory of something about normal-operation status text stepping all over the text console at which I log in and from which I startx, and that it may have been related to the fact that I was using systemd-shim rather than systemd-the-init-system and so the setup was considered unsupported by the systemd maintainers, but I'm not even certain that that was the same problem. (Of course, systemd-shim isn't even an option anymore.) I thus want to avoid letting logind run, and as far as I can tell, doing that without breaking other things means not letting systemd-the-package get installed - because even if I disable logind post-install by some mechanism, other things may have chosen to depend on systemd-the-package because they need logind, and may quite reasonably assume that the presence of the former means that the latter will be available for them to use. Given those experiences, I also have reservations about letting any other systemd-related daemons run without specific reason, just because I don't know what side effects they might cause - now or in the future. It's not as nearly absolute an objection, but as indicated in my first message, I don't trust systemd-the-project not to introduce behaviors which I find undesirable. > I don't think there's enough information on this thread to indicate > that there's any need to split out the package. Probably it would > make sense for someone to just try installing that package on a > non-systemd system and running systemd-tmpfiles and systemd-sysusers > and see if anything breaks. Given what Andrej Shadura wrote in reply to me this morning, I'd be surprised if anything did break, at least anything related to tmpfiles or sysusers. I don't want to "risk" (in quotation marks because there may not be much, if any, actual risk involved) my primary system on testing this, and right now I don't have any spare systems or a working virtualization environment (because I haven't been able to get libvirt, as packaged for Debian, to work properly in a non-systemd environment) to use for testing, so I'm not in a position to do that test myself. I do have a functioning virtualization environment at my workplace, so if downtime permits over the next week or three, I may be able to do that there. (Personally, I'd argue that splitting the various daemons and non-daemon tools out into packages according to which ones depend on which others makes sense purely from a "granularity of dependencies" perspective, but it's been clear for a long time that that argument is a nonstarter with the systemd maintainers.) >> The accepting of init scripts seemed to me like an essential piece >> of making sure those scripts would be present wherever they would >> be needed. Your suggestion above seems to provide a way to make it >> less essential, and thus would make moving forward easier and more >> practical. The only question is how to make sure that that other >> package would be present whenever a non-systemd init system is in >> use, and that seems like a simple matter of adding dependencies >> from the set-foo-as-active-init-system package for foo. > > Yeah, that was my thought. It also keeps the infrastructure for > supporting other init systems in its own packages maintained by > people who use those init systems, which seems likely to improve the > quality of maintenance and shorten the loop on bug fixes. The more I think about it, the more it seems like a superior approach all around. I'm sorry to have brought up the idea of the other approach by virtue of having failed to think of this one. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature