Quoting KatolaZ (kato...@freaknet.org): > Look Rick, Devuan is exactly trying to do this, in a consistent and > comprehensive way, well before it will be too late.
Exactly! I'm not only well aware of this, but mention it with approval on my OpenRC conversion Web page. > I think I know very well what you said, since I believe I can > understand English a little :) The conclusion seemed to be that since > pinning worked for your use case, there was no reason to fork Debian > and start Devuan. Not really what I said. Probably my fault for being unclear, so I'll explain: What I did (that was documented on the OpenRC conversion page) sufficed to prove that common claims about deep and pervasive systemd-dependency problems in Debian 8 have been vastly exaggerated (I list in detail the ones that actually exist). Also, I show that it's trivial to make Debian 8 run just fine using one of the four other packaged init systems -- with high confidence the other three also work great, and also nosh (compatible third-party package) -- as long as you don't need NetworkManager, a couple of packages from five bloatware DEs, the GNOME-oriented metapackage for HPLIP, and a couple of miscellaneous obscure apps (such as daisy-player). That is not, in itself, a systemd cure for _all_ of Debian-stable. Some people through bad judgement like NetworkManager ;-> , and through equally questionable judgement wish to install the entire kitchen-sink suites of GNOME, MATE, Cinnamon, KDE, or Razor-qt. Moreover, other irksome dependencies may arise, though (given release policies) very likely not until Debian-stable is Debian 9 'Stretch' at the earliest. To be sure to be able to keep the DE freaks happy, as well as to ensure ability to deal with future annoyances, more is required -- such as repos of fix-up packages. Yours, mine, Devuan's, whoever's. This is what Siduction and Aptosid already do, to run a Debian-variant community based on an enforced policy, in their case 'we will further stabilise the package stream in Debian-unstable'. Which works great, by the way. There are numerous ways to enforce a local (or limited-interest) policy on a distribution's offerings. That is one of them. I list in my OpenRC conversion page a number of ways to overcome dependency problems: find a third-party repo's package that's built better, rebuild the package locally using dpkg-buildpackage or debuild (i.e., using different build options), make a new package using debhelper and upstream source code. The results of any of those can then be republished as part of a package repo. A number of people getting together and pooling their third-party repos for that purpose would be closely analogous to Siduction and Aptosid's repos that fix-up Debian-unstable. > Well, you know better than me by now that each user tends to put > himself at the centre of the world, and is normally biased in thinking > that his or her use case is so common that there is no reason why > people should need anything else. Truth! ;-> > Reality is a bit more complicated than that, and ways more colorful :) I was actually curious which of the packages I list -- or any I might have missed through error -- you saw as constituting 'a few compromises'. My page was clear about my use-case, and the ones that the page does and doesn't hit. I have absolutely no problem with others considering any of the unavailable packages important, but I'm curious about which one you did, and why. > There will probably come a day in which the amount of work you need to > do in order to work around blockheaded distro policies will be so > large that you would be better off using some other distro, if you can > find any other distro around that does not have the same problem. Over the 23 years I've been a Linux user, I've heard that said at least thirty or forty times for every time it's proven true, though. Managing a system built up from H.J. Liu's root & boot floppies by fetching and compiling tarballs in 1993, now, _that_ was too much work. Hearing about Slackware was a godsend. > Or you will be forced to make your own distro (which is something that > almost anybody with a basic understanding of Linux should be capable > of doing). I was co-maintainer of a Red Hat Linux variant around 1997-8 written for a cybercafe I helped build, and so I probably _could_ do it again, but would not do so without a very good reason that I can't offhand imagine having. (We needed much better NFS/NIS than RHL furnished.) More to the point, it would almost certainly be smarter to use measures such as I've highlighted above (again). > I call it duct tape, because if I choose a distribution like Debian > Jessie, which has 42000 packages available, and then I end up being > able to use roughly 60% or 70% of them if I don't want systemd around, > then what I need is another distribution, and if it is not just know, > it will be the case in the near future. Your math (or 'maths' as the Brits would say) is off. Feeding my list of problematic packages' names from http://linuxmafia.com/faq/Debian/openrc-conversion.html through an ugly awk and sed recipe (mine), to get uniq'd package count: Litte-Datamaskin:tmp rick$ wc -l packages3 [1] 97 packages3 Litte-Datamaskin:tmp rick$ ...97 Debian 8 packages' dependency chains resolve in some fashion to systemd (unless I've missed any; corrections welcomed). I'm sure 42000 is very close, but we might as well get the exact number: root@mini:~% grep Package /var/lib/apt/lists/*Packages | wc -l 43671 root@mini:~% Percentage of Debian 8 packages you can use of you don't want systemd around (again, unless I've missed any) is thus: (43671 - 97) / 43671 * 100 = 99.77% (FWIW, current Debian-unstable, comprising as above main + contrib + non-free, has 52750 packages. I just checked.) > Debian used to be one of the few distributions which enforced > basically one policy: the package management system and the dependency > ecosystem. Apart from that, you could have a countable (meaning, > potentially infinite) set of different incarnations of Debian, one for > each of the countable operational policies needed by its users. Debian > was providing the tools, you were implementing your own policy, which > is a very successful common practice in the unix world. On about Day Two of my using Debian as a server platform, I found that I needed to also deploy Leafnode 2.0beta in order to support local NNTP newsgroups gated to my Mailman mailing lists. So, I comiled from source tarball into /usr/local/* . Later, deciding that was a bit dumb, I replaced that with a locally compiled and built deb package constructed using debhelper. So, I guess you could say I've been a practitioner of 'it's nice to have a local policy, but some times you need to supplement or correct it locally' since about Day Two. Anyway, I certainly agree that each additional measure one must take to countermand the policy implicit in the package management system and dependency ecosystem (along with the set of software delivered via those systems) adds incrementally to the work, and eventually makes onee seek alternatives. Distro-switching is of course one -- and one I've elected four times since 1993 (not counting pre-Linux switching before that). My point is that there are also others of less-drastic measure that may suit -- in much the way that Siduction is an alternative to orthodox Debian-unstable that I don't need to maintain myself, and that didn't require forking the distribution. > You know better than me that the main reason why you and me are > discussing this matter is that systemd is trying very hard to impose > "one-and-only-one" policy to the whole Linux ecosystem. Truth. Though it was the irritating coincidence of the GNOME packagers deciding that gdm3 needed to depend on libpam-systemd (instead of ConsoleKit -- or something like that), which depends on systemd -- and that systemd-shim wouldn't suffice for some reason -- that _solely_ made that an issue in Debian, because those fools (the Debian Project) failed to make the IMO more-rational judgement that 'Well, if GNOME has become _that_ bad a brittle dependency hairball, we'll need to switch DEs.' The thin wedge that introduced the dependency hairball was the 'multi-seat' support API (that IIRC drove the libpam-systemd -> systemd dependency chain. I'm pretty sure that's the issue in all of GNOME, MATE, Cinnamon, KDE, and Razor-qt. Without that, it'd be just 'Oh, the Freedesktop.org CADT people are breaking their stuff again.' > The rest is mostly rhetoric that we auld aunties like to sprinkle over > long emails, for our own pleasure :) Quite so. As the Aussies say, 'Good on ya!' [1] 'litte-datamashin' is my laptop (hostname means 'little computer' in Norwegian). 'mini' is my test VM for Debian 8. 'uncle-enzo' AkA uncle-enzo.linuxmafia.com is my server (a reference to Neal Stephenson's _Snow Crash_, of course). _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
