Quoting KatolaZ (katolaz@???):

> 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).