Hullo, I'm the rat bastard who wrote http://linuxmafia.com/faq/Debian/openrc-conversion.html and is thus either ignorant or a very sadistic systemd hooligan.
Hi, Jaromil! You and I have corresponded in e-mail, and you'll recall that I like Devuan, appreciate its work, and follow it with interest. Normally, I follow dng (intermittently) only via its Web archive, because I don't really have time for more mailing lists, but I'll be on here for at least present discussion for a while. > Someone on the linked thread made a lot of arguments about how > Devuan was "an operative overreaction" in response to Systemd; Operatic, not operative. Far as I can tell, Devuan was a operatic overreaction, and by no means the most efficient way to deal with the problem. Yet, (1) their repos are compatible, so their work effectively _does_ supplement and assist Debian, and (2) again, it's their spare time to use as they please, when all is said and done. Downthread, I gave examples of how the third-party repos of how Aptosid or Siduction, among others, successfully maintain Debian-variant distros enforcing their policies using third-party repos and package pinning, without a distribution fork. So, that not only can work, it does work. On the other hand, I have absolutely no problem with your deciding to fork the distribution instead, and appreciate your work. 'dev' wrote: > You can pin all you want, and force-remove all you want, but > one day there will be a package you need (let's pretend it's > linux-libc-dev-xxx.x.x) which will have the hinge-pin baked-in. You > can no longer update libc. Really? The GNU libc package is going to suffer a dependency chain that requires package systemd? Would you like to wager either US $100 or €100 that this is going to happen in Debian-stable by the end of 2017? I will offer you 1:10 odds against. This wager offer will be extended for two days from the timestamp of this posting, and is extended to you _specifically_. If you wish to accept, send mail on-list to do so, and mail offlist giving me meaningful identification data for yourself (as obviously I would not make such a money deal just with a pseudonym named 'dev'). > Obviously, some packages are already at that point and already > have dependencies baked into some of the fundamental linux packages > everyone runs on Linux. Which package is that? NetworkManager? I do not concur about NetworkManager being essential. ConnMan is significantly better IMO for example, and was never a dependency hairball. hplip? That would be a serious problem if you _actually_ could not install the HPLIP software, but that software is actually in packages printer-driver-hpcups and printer-driver-hpijs, which have everything you actually need. It's very annoying that Debian package 'hplip' is a dependency hairball with GNOME glue that resolves hplip -> policykit-1 -> libpam-systemd -> systemd. However, that packaging error doesn't prevent using HPLIP. (Page covers this in detail.) daisy-player? gdm3? gnome-core? Which package is a 'fundamental Linux package everyone runs on Linux'? I ask merely for clarity. I did a fair amount of work with apt-cache on a Debian 8 'Jessie' test system in writing up http://linuxmafia.com/faq/Debian/openrc-conversion.html to see which packages suffer dependency chains resolving to systemd. If I've missed any, please advise, and I'll fix the omission and gratefully credit whoever sends me the correction. If I haven't missed any, please advise about which of the listed packags are 'fundamental Linux packages everyone runs on Linux'. For the record, as a Linux user since 1993, I don't find any of the listed packags essential for my own use-cases. > Devuan *is* relevant because any systemd bloat which makes it's way into future packages can be delt with by the Devuan community. Strongly agree! And please note that I am very far from wishing to claim Devuan irrelevant. > I mention all this becuase I took the "deb 8" pinning challenge today > and it failed miserably. I'm sorry to hear that, but let's look at particulars. > Systemd is vendor lock-in and there is no other way to explain it when > "apache2-common" cannot be installed due to libsystemd0 dependency. Ah, _libsystemd0_. Thanks for the clarification. You were not talking about a dependency that resolves to package systemd, but rather one that resovles to package libsystemd0. Well, then, that clarifies things. We can now agree to disagree about an almost certainly functionally meaningless package dependency on libsystemd0 equating to a system being chained to system, and thus a qualifying example of 'the tentacular and insidious reach of systemd'. Quoting my page: A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems entirely harmless. I respect the developers behind Devuan, and know they have done & are doing a great deal more than just omitting systemd, but it seems to me that there was a lot of hyperventilating over mere presence of a lib that's doing zero harm just sitting there. If worried about it, run a nightly cronjob that ensures /lib/[$ARCH]-linux-gnu/libsystemd.so.* is set to 000 permissions. I did so on my Debian 8 'Jessie' test system, and nothing broke in my limited checking. That did not include Apache httpd: It didn't occur to me to do that at the time. (It's just a VirtualBox VM on a laptop, and the thought of running a major Web server there didn't occur to me.) In the name of science, I'd be willing to try that -- or you could. I'm reasonably certain that the asserted dependency of Debian-stable's apache2-common package on libsystemd0 is essentially bogus. Would you like that investigated? Somehow, I suspect you aren't interested, as you paid no attention to how painstakingly I qualified what the page said, when you read it. Now, indeed the page may contain errors. I will be grateful if they might be pointed out. And certainly I not only might be ignorant, but I _am_ ignorant. I was born that way, and will die that way -- but I might pick up a few clues before I die. I most certainly do make mistakes. I welcome being shown where they are. > I took the "deb 8" pinning challenge To be very clear, I nowhere and never posed a "deb 8 pinning challenge". What I did was document (on a Web page) the results of an experiment with a Debian 8 'Jessie' test system where I carried out a suggestion from without-systemd.org about how to convert such a host to OpenRC and prevent any subsequent intrusion of systemd. Because people on Don Marti's linux-elitists mailing lists had predicted in 2015 that such a measure would be pointless because I'd find essential packages' installations blocked with 'Some packages cannot be installed' diagnostics, I decided to see for myself _which_ packages cannot be installed on a system. I documented all such packages to best ability. My conclusion is that such a system fully meets my own use-cases, which involve servers and to a limited degree desktop computing with window managers but (by preference) no Desktop Environments. Also, some DEs are installable in their entirety, while five (GNOME, MATE, Cinnamon, KDE, and Razor-qt) can be installed almost in their entirety -- though I personally have no interest in DEs. I _believe_ I competently documented all those results. If I have erred in any of the factual data, please advise. You don't like the page? Sorry to hear that; fortunately, there are countless other pages on the Web you might like better. If you do _not_ see errors on that page -- and apache2-common resolving to a chain that includes libsystemd0 does not indicate error -- then I would appreciate your ceasing to claim incorrectly that it does. Meanwhile, Works for Me.[tm] Furture work on that page or related pages could include: 1. Use 'equivs' to substitute a placeholder package in place of libsystemd0, and make sure nothing of interest (including Apache httpd) breaks. 2. Test mdev for server deployments. (Dump udev.) 3. Test grsecurity / PaX-patched kernels and see how much other Freedesktop.org cruft can be eliminated without functional problems. E.g., what if anything actually needs D-Bus IPC, and can those of us who don't care about GNOME and KDE remove it completely without missing it? -- Cheers, "Why struggle to open a door between us, Rick Moen when the whole wall is an illusion?" r...@linuxmafia.com -- Rumi McQ! (4x80) _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
