:: [DNG] Why Debian 8 Pinning is (or i…
Página Inicial
Delete this message
Reply to this message
Autor: Rick Moen
Data:  
Para: dng
Novos Tópicos: Re: [DNG] Why Debian 8 Pinning is pointless
Assunto: [DNG] Why Debian 8 Pinning is (or isn't) pointless
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?"
rick@???                                                     -- Rumi
McQ! (4x80)