:: Re: [DNG] Why Debian 8 Pinning is (…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Rick Moen
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting KatolaZ (katolaz@???):

> And again, this is more or less what Devuan is doing :) We are still
> using 99.5% of the packages directly from Debian. All the packages
> developed for Devuan work with little or no effort at all in other
> Debian-based environments. We are probably just saying the same thing,
> in two different ways :)


True, that. I'm not only aware of (and appreciate) that that's what
Devuan is doing, but specifically note that fact in my OpenRC conversion
Web page -- pointing out the ability of Debian users to use those repos
among other options.


> Me? No package at all.


OK, fair enough. I'm sorry if I came across as irritatingly
literal-minded, but when one Dng poster says my page's comprehensive
list of impaired packages includes 'important' packages, another says it
includes 'fundamental Linux packages everyone runs on Linux', and
another (you) says implementing the page's tips entails 'a few
compromises', I wonder what _specifically_ they are referring to.

(I am also extremely skeptical of vagueness in areas where what is being
articulated sounds suspiciously like polemics. See also your assertion
that '60% or 70%' of Debian 8 packages lacking systemd dependency, when
the correct figure can be easily determined to be 99.77%. So, I _like_
specific and verifiable. Specific and verifiable are good.)


In my view, part of the advantage of creating detailed documentation
(such as my modest Web page) is that any reader can decide for
himself/herself what is important and what course of action to take.

And I should stress that the intent was merely to say 'I tried this to
solve a problem, and here are details of what I found, some suggestions
about ways residual problems might be dealt with, and clarifications and
some links about init systems. It might be useful to you. Or not.'
People on this mailing list keep treating the page like it's a polemic
to attempt to convince readers to do what it says, which seems more than
a bit crazy, to me.



> My computing is so simple and archaic that systemd cannot *currently*
> affect it in any meaningful way. But unfortunately I profoundly hate
> (and I am sure you will appreciate that this is the first time I use
> this word in our discussion) the change-for-change-sake attitude.


Yes, it's the Freedesktop.org CADT problem. I hope people on this list
know the CADT meme, right? https://www.jwz.org/doc/cadt.html

(I know the original CADT, Luis Villa, now an attorney. He's far more
reasonable than Jamie Zawinski's sarcastic essay would suggest, and has
a worthwhile explanation for the bug-handling that inspired the essay:
http://lu.is/blog/2014/03/28/i-am-the-cadt-and-advice-on-needinfoing-old-bugs-en-masse/
)

CADT is one problem factor in the Freedesktop.org codebases in question
(systemd/udev, udisks2, PolKit, upower, packagekit, etc.), and tangled
dependency graphs are another. And the gullibility of the GNOME people
(AFIACT, both upstream devs and maintainers of the Debian packages)
in falling for that suite of code was IMO the triggering factor in
setting off the crisis (along with the Debian Project failing to then
reassess its choice of GNOME as default DE).


> I hate being forced to use by default a software developed to solve a
> non-existing problem in a so intricate way that you barely recognise
> it as a solution to any problem at all.


{shrug} I just deal with it.

Experience suggests that dislike is not a plan, and is only an
unreliable motivator. The military people have a useful acronym for
this situation: OODA -- observe, orient, decide, and act (which is
a mnemonic to aid effective planning).
https://www.mindtools.com/pages/article/newTED_78.htm


> I am convinced that it is still possible to do things in 2016 (and in
> 2017, and in 2018, and until early 2038, fot that matter) avoiding the
> massive bloatware that they want to convince us to accept. And I am
> here to prove it, as you are. Maybe with different means.


Yes, indeed.

Being mostly in server computing, and eschewing DEs by preference, I had
been able to ignore the controversy as a GNOME problem, and avoided it
by declining to install anything from GNOME with too ridiculous a
dependency train. (So, for example, I find the dependency list of
packages abiword and gnumeric acceptable, but not some other GNOME
applications, and most definitely not, for example, 'evolution'.)

I've gradually become aware that udev is a liability, and am now on
guard against other Freedesktop.org CADTware. Rob Landley's work making
mdev available will probably solve my udev problem (along with an
'equivs' item claiming falsely that udev is present).

People here keep suggesting that approaches like mine approximate
maintaining my own distribution, and are a strategic mistake. I do not
agree with the premise: I'm doing (and contemplating) nothing
_remotely_ like maintaining my own distribution. My mother didn't raise
any fools: The whole point of leveraging others' work, like Rob
Landley's, is to avoid doing so.


> That's your opinion, and I respect it. My opinion is different, and
> probably won't change, so I am sure you will respect it in turn.


Naturally!

> Do
> you think all the guys and ladies here are just a bunch of assholes
> who didn't think about the possibility of pinning, and dpkg-buil-ding,
> and mixing repos, and duct-taping the oddities introduced by systemd
> one after the other? :)


I would not dream of so asserting. But technically I wasn't present for
what was investigated, so I merely assume that people intelligently
grappled with the problem and did what seemed best based on their
priorities and available information.

I'm just a sysadmin who tried something, documented it, and speculated
that other, less-drastic ways of perpetuating a no-systemd
Debian-variant community than a fork would have also worked.

I might be right; I might be wrong. But I cannot see that my holding
that view would be a legitimate offence to anyone. Remember, I did
_not_ come onto this list to blurt out that opinion. That would have
been being a jerk. Rather, Mr. Litt decided, in his great wisdom, to do
that.


> We don't need to prove here who is better than whom.


Well, I _am_ better-looking. ;->



> Again, I don't use GNOME, but if I can't shutdown from GNOME this is a
> little daily PITA.


I care so very, very little about GNOME at this point that I am not
going to even try researching how to fix broken shutdown controls
resulting from not having systemd-logind -> libpam-systemd -> systemd
present. I _might_ be able to look up that problem, but I'm kind of
done with attempting to help fix GNOME problems. I just assume it's
broken.

Thus, no offence intended, good people, but when Devuan produces a fully
functional GNOME3 stack with everything working, I'm very unlikely to
recommend it to people because, in my experience, GNOME is a brittle
dependency hairball, too much trouble, and nearly impossible to diagnose
when it has problems. Same with KDE4.


> I don't need hplip, but if I do (and, just to mention, if I admin a
> couple dozens machines which do), then hacking around a solution at
> each dist-upgrade is a PITA.


{sigh}

Maybe you didn't read what I wrote on my Web site. There's no problem
with the Debian HPLIP _except_ misleading package naming.

Basically, _all_ of the HPLIP contents you actually want are in packages
printer-driver-hpcups and printer-driver-hpijs. Install those, with the
CUPS print engine, and you have full, working HPLIP. No 'hacking around
a solution with each dist-upgrade' is ever required.

The point is: You simply do not need the package _called_ 'hplip' (an
omnibus metapackage that includes GNOME glue), and merely avoiding the
error of installing it permanently (AFAICT) avoids dependency problems
and GNOME disease.



> If the systemd-lot wants to push "sessions" to the point of asking
> screen and tmux to change their code base in order to adhere to the
> systemd-lot view of the world, this is not just a PITA, but an insult
> to the way free software is normally developed, i.e. to cooperate with
> more free software.


Well, they can _want_ that, but -- seriously -- do you honestly think
the maintainers of GNU screen and tmux would have any reason to do so?
This seems frankly like another fantasy apocalpse, like the fellow
upthread who was burbling about a future systemd dependency in GNU libc.

Caution about CADTware is laudable, but -- seriously: GNU screen and
tmux? I really don't think so.


> I really hope Devuan will be proven wrong by a strong community effort
> able to force reason back in the Debian quarters.


This isn't the way history works, because you never get to re-run
history with different inputs. Obviously. So, there is no 'proving
wrong' by any rational standard.

-- 
Cheers,                      <blazemore> omg i love this song
Rick Moen                    <blazemore> Now playing: Unknown Artist - Track 2 
rick@???                      @ 128 Kbps. (0:47/3:24) 
McQ! (4x80)                  <Javi> blazemore:  Yeah, that's a bad-ass song.