Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Hendrik Boom:

> Given the mix, I'd prefer to hear him out rather than ban him. 

You-plural should _most_ certainly ban me if Dng cannot accomodate
occasional polite mocking of what I see as ideological ranting and
tunnel vision that notably fails to get anything done.

I couldn't help noticing that my friend Mr. Litt -- the man who insisted
you hear all about my views (I didn't) -- spent vast amounts of time
posting impassioned stump-speeches on debian-user and accomplishing
nothing at all.  By contrast, when I finally got around to grappling
with the indeed troubling and serious problems in Debian 8 'Jessie', I
spent two days finding good workarounds and documenting them (along with
their limits) on a Web page pro bono publico.  Which approach do _you_
think accomplishes more?

(Please note I did _not_, and would not, denigrate Devuan Project's
actual _work_, just the dumb ranting stuff.  That work is something I
expect will accomplish a great deal more and help a lot more people.)


> ...deniable.

I believe you are crediting me with a _great_ deal more subtlety
than anyone who knows me would _ever_ attribute to yr. humble servant,
who's about as subtle as his garden's habanero chilis, and whose
writings aim to clarify what he _thinks_, not play tiresome games to
rile up strangers.  I seek _clarity_.  If you insist on being offended,
that is not my remit.

(However, I _am_ still waiting to hear about the Tory of the Blind Man
and the Elephant, at our UK friend's earliest convenience.  If he feels
trolled over that, I'm sorry he can't take a joke.)

So, I'd be glad to settle for people gradually ceasing attempting to
enforce software religion here and more consistently behave like a 
software project.  I don't like fanatical religion.  It killed my friend
and congressman, Leo Ryan, at Jonestown, after all, so I tend to take it
rather personally and stomp hard on it when I see it.  But if you'd
prefer to ban me for not singing in that particular choir, that works,
too.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[info at smallinnovations.nl]

On 29-07-16 21:39, Jaromil wrote:


I think most people clashing with Rick here may want to stop for a
moment and realise Devuan does not need fan-boys, converted people or
preachers as much as critical and constructive minds that go across
all what we are doing and, besides encouraging it, also envisions
flaws and limits. This is what we always need to encourage if we don't
want to end up like Debian today. The capacity to listen to critical
postures is what makes us different from the dynamics surrounding the
systemd avalanche.

Rick is a seasoned contributor to all sorts of good developments in
gnu/linux world, he is provocative and witty, definitely not a
troll.


Your "definitely not" is not mine. If it looks like a duck, swims like a 
duck, quacks like a duck it probably is a duck.

So i will take him for a troll until the opposite has been proven.

Grtz.

Nick

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Walter (si...@gikaku.com):

> First of all, if my words mean nothing to you, you should ignore
> them.

OK, ignoring the rest.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/30/2016 03:55 PM, Rick Moen wrote:

Quoting Simon Walter (si...@gikaku.com):


Isn't that what's being discussed? When did I say the things you
said were opposition for the Devuan Project?


'disagree with a fork of Debian'.

I've made clear what I said, and what it meant and didn't mean.
You've attempted to distort that into an attack on the Devuan Project,
which is crazy talk and fanaticism -- as Jaromil was kind enough to
acknowledge specifically -- and I've said we have nothing more to
discuss on that matter.

_And_, the kicker, one of the things I was known for earliest in the
Linux community is an essay on forking explaining why forking is a
necessary and important right.  Which you should be aware of because
it's been mentioned here.

You are wasting your time and mine.



First of all, if my words mean nothing to you, you should ignore them. 
Don't answer a fool - me being the fool in this instance.


Secondly, I should not be aware because I don't read everything you 
write here because it's too wordy for me. I've enjoyed some of your 
writings in proper, but wasn't aware of that particular one. I look 
forward to reading it.


Thirdly, I've already said, I don't disagree with what you said. I just 
don't like how you come across sometimes and tried to explain how you 
might make someone feel. My attempts at satire and explaining social 
matters have backfired and left my foot in my mouth. Now you think I am 
trying to distort what you say. I wouldn't dare and apologize if that is 
how it was understood.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/30/2016 02:57 PM, Rick Moen wrote:

Quoting Simon Walter (si...@gikaku.com):


Which is why it could be construed that you disagree with a fork of
Debian - a for of Debian as in "A fork of Debian that could be said
to have been started because the default init system in Debian
became systemd." - that fork of Debian - not a theoretical fork.


You know, if you are going to call 'In my opinion, the goals of this
project could have been achieved through less-arduous means' _opposition_
to the project -- a project I explicitly like and appreciate -- then
that is fanaticism, IMO, and we have nothing more to discuss.


Isn't that what's being discussed? When did I say the things you said 
were opposition for the Devuan Project?


Trying to explain why *some* people might see you a certain way after 
you express that you don't understand why said people see you said way 
is a little different than saying you are that way.


But never mind. You seem offended. So it was a bit pointless for me to 
try. Sorry dude - (if I can call you that). Obviously I don't disagree 
with what you said or we would be discussing those details and not what 
appears to me to be social matters.


Where there is passion, there may be fanaticism. What am I doing trying 
to explain any further? I must be insane. ;)




Fortunately, I am reasonably certain you don't speak for the Devuan
Project in this regard.



Fortunately, I do not speak for the Devan Project in any regard except 
as a recommendation to some other admins who have utter curses towards 
systemd within ear shot.


A good day/night to you sir!

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Walter (si...@gikaku.com):

> Which is why it could be construed that you disagree with a fork of
> Debian - a for of Debian as in "A fork of Debian that could be said
> to have been started because the default init system in Debian
> became systemd." - that fork of Debian - not a theoretical fork.

You know, if you are going to call 'In my opinion, the goals of this
project could have been achieved through less-arduous means' _opposition_ 
to the project -- a project I explicitly like and appreciate -- then
that is fanaticism, IMO, and we have nothing more to discuss.

Fortunately, I am reasonably certain you don't speak for the Devuan
Project in this regard.

-- 
Cheers, Grossman's Law:  "In time of crisis, people do not rise to
Rick Moen   the occasion.  They fall to the level of their training."
r...@linuxmafia.com  http://linuxmafia.com/~rick/lexicon.html#grossman
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/30/2016 04:18 AM, Rick Moen wrote:

Quoting Steve Litt (sl...@troubleshooters.com):


In all fairness to Rick, he was making his statements on SVLUG, and
then, on DNG, *I* referenced the SVLUG archive of the SVLUG discussion,
and only then did he repeat his assertions here.


And my assertions stated that I like Devuan and appreciate it.  All I
said that threw you into a tizzy was that I estimated that its
objectives could also have been achieved through lesser means.


Which is why it could be construed that you disagree with a fork of 
Debian - a for of Debian as in "A fork of Debian that could be said to 
have been started because the default init system in Debian became 
systemd." - that fork of Debian - not a theoretical fork.



People who insist on treating me like an enemy are being rather stupid.
Those who persist in attributing to me statements I've never made and
views I don't hold are being _very_ stupid.


Of course I should be more sensitive, but hopefully I didn't make you 
feel like an enemy. I am merely trying to help explain why you might 
appear to some people that way, but now there is no point in me chewing 
on my foot any longer, is there?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Jaromil (jaro...@dyne.org):


[much snipped]

Jaromil, you are a prince.

Yes, I am sarcastic and inclined to mock when I think something is 
fanatical and/or purblind.  I am often wrong, and all too often woefully
undercaffeinated.  I also have a nasty habit of backing people into
corners, which I need to stop doing.

Which is to say, all too human (or perhaps I'm a commentbot masquerading
as a human), but not the enemy of anyone here, and not posting just to
provoke or annoy.

> At last, I for one need to recognise my error in interpreting Rick's
> article as a denigration of Devuan.

Well, I perfectly understand the urge to initially say 'Oh, not another
net.random slagging us unfairly'.  You're busy; I don't expect you to
drop everything just because I put up a Web page.  Actually, I applaud
your having until today worked on Devuan rather than reading my
doodlings.  It's a lot more important.

> But also I think: Rick you may want to update it now that the
> systemd-shim is falling unmaintained (see golinux mail), since a lot
> of the assumptions you put forward won't be really sustainable anymore
> on the long term.

That's a good idea.  I'll do that.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Walter (si...@gikaku.com):

> Rick, that's exactly what I was talking about. You might be well
> intentioned, but in so many words you are saying that you disagree
> with a fork of Debian.

Um, excuse me, but I didn't say that.

> If you really think Devuan is wrong, then flight it harder.

Um, excuse me, but I like Devuan.  I look forward to using what it
produces, either by borrowing packages from its repos or by running it.  
This is why, for example, my OpenRC Conversion page suggests access to
Devuan's repos to solve package problems.

> You seem like a smart guy and seem well intentioned. Others may be
> able to use your good advice. So maybe try and appear a little more
> open minded and others might open up a bit too.

Here's an idea:  Stop attributing to me views I don't hold and never
expressed.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting info at smallinnovations.nl (i...@smallinnovations.nl):

> On 29-07-16 01:43, Rick Moen wrote:
> >Quoting info at smallinnovations.nl (i...@smallinnovations.nl):
> >
> >>I am a sysadmin myself and why in hell would i like to rebuild local
> >>packages?
>
> >One of my worst and most annoying habits is to give reasoned and
> >useful answers to rhetorical questions.
>
> Hardly, you act like a troll quite a long time now.

In the name of saving time, I'll just acknowledge that I'm an awful
person in every conceivable way, so we can move on to possibly more
interesting matters of software and host administration.

Unless you're just much more comfortable with personal abuse than you
are with system adminstration, in which case please plow right ahead.


> >Great, so answer me a question:  How are you getting a system without
> >libsystemd0 today?

> Waiting for Devuan or using something else then Linux as i told in
> the part of my message  you did not quote.

Ah, so today you _have_ no solution.

Well, I documented a number of them that interested parties can use
today.  Which brings me back to where we were before, except for some
reason you are complaining about those solutions and asking
why-would-I-use them.

I suppose you would use one of them if you wanted to have a solution
today.  If you don't want a solution today, you would not.

As it turns out, apparently you do not want a solution today, but wish
to do nothing today and wait for someone to provide you a solution
tomorrow.  I understand.  I do _not_ understand why you are annoyed at
my providing ones that might suffice for many _until_ Devuan has that
better way (which I will welcome), but some people just seem to like to
complain.

Enjoy the killfiling.  Perhaps if you'd done that earlier, you'd have
been spared being angry at someone who's done you no harm.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/29/2016 06:27 PM, Simon Hobson wrote:

I wrote:


... and in a place where "the IT world starts and ends with Windows" (or more 
or less did when I started here) that's not a bad result.


And bear in mind that when I started here and pointed out that as a Mac user, half of our 
internal systems didn't work properly* - the lead developer told me in no uncertain terms 
that it was my fault for not using IE6 on Windows and no they had no intention of 
"fixing" anything. My suggestion that this was a rather short sighted approach 
fell of deaf ears ... for a while - they've had to change their tune these days !


* For years I had to fire up an XP VM just to do my timesheet. As a parting gift, another 
dev just before he left had a look and fixed the one missing or superfluous (can't 
remember which) ";" in some javascript that broke this particular system on 
anything but Windows/IE6 :-/



Oh man, it sounds the same all over the world. (face palm)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

I wrote:

> ... and in a place where "the IT world starts and ends with Windows" (or more 
> or less did when I started here) that's not a bad result.

And bear in mind that when I started here and pointed out that as a Mac user, 
half of our internal systems didn't work properly* - the lead developer told me 
in no uncertain terms that it was my fault for not using IE6 on Windows and no 
they had no intention of "fixing" anything. My suggestion that this was a 
rather short sighted approach fell of deaf ears ... for a while - they've had 
to change their tune these days !


* For years I had to fire up an XP VM just to do my timesheet. As a parting 
gift, another dev just before he left had a look and fixed the one missing or 
superfluous (can't remember which) ";" in some javascript that broke this 
particular system on anything but Windows/IE6 :-/

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

info at smallinnovations.nl  wrote:

>> Great, so answer me a question:  How are you getting a system without
>> libsystemd0 today?

> Waiting for Devuan or using something else then Linux as i told in the part 
> of my message  you did not quote.

This. Plus in the meantime, using a systemd-free supported distro (ie sticking 
with Debian Wheezy on LTS).

I'm not a programmer, so what I can do I do - 'evangelise' Devuan when I have 
the opportunity, support other users of the packages I use where I can, 
'evangelise' GNU/Linux & FOSS where I can. Of course, those later two are not 
Devuan specific ...
And, I think this is a big one (though in a way it's a form & result of 
evangelism), I've been able to demonstrate at work that FOSS (and specifically 
GNU/Linux) can "do stuff" and do it well - and in a place where "the IT world 
starts and ends with Windows" (or more or less did when I started here) that's 
not a bad result.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/29/2016 01:28 PM, Steve Litt wrote:

On Fri, 29 Jul 2016 10:49:32 +0900
Simon Walter  wrote:


On 07/29/2016 10:00 AM, info at smallinnovations.nl wrote:

On 29-07-16 01:43, Rick Moen wrote:

If you can suggest an additional method, I'll be glad to amend my
list of suggestions.  Otherwise, I'm not sure what your point is.

Your point is quite clear: you do not want a fork of debian and
that is the whole point of you being vocal on this list is it not?
I suppose you are quite good in Debian politics.

Adding you to my blacklist now.


Rick, that's exactly what I was talking about. You might be well
intentioned, but in so many words you are saying that you disagree
with a fork of Debian. So of course people here will not see you as
well intentioned and a quite possibly many other negative things.


In all fairness to Rick, he was making his statements on SVLUG, and
then, on DNG, *I* referenced the SVLUG archive of the SVLUG discussion,
and only then did he repeat his assertions here.



Yup, I saw the show. ;)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Steve Litt]

On Fri, 29 Jul 2016 10:49:32 +0900
Simon Walter  wrote:

> On 07/29/2016 10:00 AM, info at smallinnovations.nl wrote:
> > On 29-07-16 01:43, Rick Moen wrote:  
> >> If you can suggest an additional method, I'll be glad to amend my
> >> list of suggestions.  Otherwise, I'm not sure what your point is.  
> > Your point is quite clear: you do not want a fork of debian and
> > that is the whole point of you being vocal on this list is it not?
> > I suppose you are quite good in Debian politics.
> >
> > Adding you to my blacklist now.  
> 
> Rick, that's exactly what I was talking about. You might be well 
> intentioned, but in so many words you are saying that you disagree
> with a fork of Debian. So of course people here will not see you as
> well intentioned and a quite possibly many other negative things.

In all fairness to Rick, he was making his statements on SVLUG, and
then, on DNG, *I* referenced the SVLUG archive of the SVLUG discussion,
and only then did he repeat his assertions here.

SteveT

Steve Litt 
July 2016 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/29/2016 10:00 AM, info at smallinnovations.nl wrote:

On 29-07-16 01:43, Rick Moen wrote:

If you can suggest an additional method, I'll be glad to amend my list
of suggestions.  Otherwise, I'm not sure what your point is.

Your point is quite clear: you do not want a fork of debian and that is
the whole point of you being vocal on this list is it not? I suppose you
are quite good in Debian politics.

Adding you to my blacklist now.


Rick, that's exactly what I was talking about. You might be well 
intentioned, but in so many words you are saying that you disagree with 
a fork of Debian. So of course people here will not see you as well 
intentioned and a quite possibly many other negative things.


If you really think Devuan is wrong, then flight it harder. Be more 
evangelical about it. Why not write a diatribe about it on your website 
and post the link wherever you like? But please don't hide your disdain 
for Devaun in intellectualism. You think we are idiots? Just call us 
idiots and be done with it. I get labeled an idiot every time I walk out 
my door. It doesn't mean much to me.


You seem like a smart guy and seem well intentioned. Others may be able 
to use your good advice. So maybe try and appear a little more open 
minded and others might open up a bit too.


That's my unsolicited advice. m(__)m
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[info at smallinnovations.nl]

On 29-07-16 01:43, Rick Moen wrote:

Quoting info at smallinnovations.nl (i...@smallinnovations.nl):


I am a sysadmin myself and why in hell would i like to rebuild local
packages?

One of my worst and most annoying habits is to give reasoned and useful
answers to rhetorical questions.

Hardly, you act like a troll quite a long time now.

   So:

You might decide to rebuild a local package lacking a dependency on
libsystemd0 if you feel a need for it and what you want isn't available
in any even-easier fashion.



I simply want a distro without systemd.

But wanting it doesn't _get_ you that -- NOR does it get you a system
without libsystemd0, either.  Thus my point.

There are more distros then Debian as you well know.




When i cannot get one i will start pinning or rebuild local packages
but not one moment earlier.

Great, so answer me a question:  How are you getting a system without
libsystemd0 today?
Waiting for Devuan or using something else then Linux as i told in the 
part of my message  you did not quote.


To my knowledge, you would need to follow one of the suggestions
currently included on my OpenRC Conversion page's list of 'overcoming
dependency obstacles' tips, which are (a) equivs, (b) find a third-party
repo with a rebuilt (or differently built) package, (c) wait for Devuan
to produce one, (d) rebuild the package locally, or (e) construct a deb
package using the upstream source tarball using debhelper.  (I also
mentioned on this mailing list the creative idea of overwriting the
problematic library with a nearly null-function one, to fool apps
claimed to merely see if a library can be opened without being
particular about what's in it.)

Is there an additional way of achieving that result today?  Or are you
merely saying you really, really, really want one?

You 'cannot get one' today for a number of packages including (according
to one poster here) ClamAV.  So, how are you achieving it _today_, sir?


If you can suggest an additional method, I'll be glad to amend my list
of suggestions.  Otherwise, I'm not sure what your point is.
Your point is quite clear: you do not want a fork of debian and that is 
the whole point of you being vocal on this list is it not? I suppose you 
are quite good in Debian politics.


Adding you to my blacklist now.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (si...@thehobsons.co.uk):

> So when someone states that "it's just a library, it doesn't do
> anything" then that needs taking with a pinch of salt because once
> anything calls one of it's functions, then that library can do lots of
> stuff.

On the other hand, when the person says 'it's just a library; it doesn't
do anything'[1], _and_ accompanies that with the crucial detail that the
reason this _particular_ library doesn't do anything is that it's merely
interface code to something else you have deliberately left out, _and_ 
went to the trouble of explaining that a library can do anything except
be directly invoked as an executable, _and_ scrupulously referred you to 
good documentation on libraries so you can learn what they are if you
honestly do system administration but don't know what a library is ---
then maybe you should keep the salt in its box, because you never know
when you might need salt for something other than failing to understand
information in context.

> So the point I've been making before is that, even if libsystemd0
> "does nothing" now, we can't be complacent that it won't change.

And package maintainers are evil corrupt collaborators who wouldn't
catch this and reject the change, and the entire Linux community would
be incompetent to notice and take remedial action.  

Of course!  How did I miss that?

> OK, this many be paranoia 

No, really? 


[1] That person endeavours to not write run-on sentences, so would in
fact use a semicolon rather than a comma.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> > Who's the Tory of the Blind Man and the Elephant?  Theresa May?  ;->

Quoted to remind people that I never learned who this mysterious
Conservative Party MP is.  Curious Minds Want to Know.[tm]

> Which brings us full circle. Simon doesn't want to keep playing these
> games, wondering what kind of workaround he'll need next, as Lennart
> decides to subsume yet another Linux functionality, or Debian's "DDs"
> make yet another poor decision on dependencies. So he chose to go with
> the fork.

Great, he 'doesn't want'.

Now that that's settled, what is he going to _do_, to achieve what he says
he _does_ want.  And when I say 'do', I don't mean the
ranting-on-mailing lists part, but rather actually do.

> I don't have the tech chops to know all the various ways Lennart can
> screw up my life, nor do I have the technical chops to know (without
> huge experimentation) how to work around Lennart's latest incursion.

Well, gosh, you _could_ read my Web page.

That's what I wrote it for.  However, cannot lead the horse to water, of
course.

> I know the incursions will keep on coming

Yes, the sky is always falling.  News at 11.


> And then there's this: I don't know anything about Simon's feelings,
> but Debian's actions of 2014 disgust me.

That's nice.  Me, I'm a bit busy managing systems.  Which involves
mostly dealing with software and making things work.  There have been
times in the past when you've written a few things about that, too.



> For me, continuing to use Debian is an impossibility. 

Yes, we know you're a Void Linux user.  Thus all the extremely
impassioned Devuan fervour.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting info at smallinnovations.nl (i...@smallinnovations.nl):

> I am a sysadmin myself and why in hell would i like to rebuild local
> packages?

One of my worst and most annoying habits is to give reasoned and useful
answers to rhetorical questions.  So:

You might decide to rebuild a local package lacking a dependency on
libsystemd0 if you feel a need for it and what you want isn't available
in any even-easier fashion.


> I simply want a distro without systemd.

But wanting it doesn't _get_ you that -- NOR does it get you a system
without libsystemd0, either.  Thus my point.


> When i cannot get one i will start pinning or rebuild local packages
> but not one moment earlier.

Great, so answer me a question:  How are you getting a system without
libsystemd0 today?

To my knowledge, you would need to follow one of the suggestions
currently included on my OpenRC Conversion page's list of 'overcoming
dependency obstacles' tips, which are (a) equivs, (b) find a third-party
repo with a rebuilt (or differently built) package, (c) wait for Devuan
to produce one, (d) rebuild the package locally, or (e) construct a deb
package using the upstream source tarball using debhelper.  (I also
mentioned on this mailing list the creative idea of overwriting the
problematic library with a nearly null-function one, to fool apps
claimed to merely see if a library can be opened without being
particular about what's in it.)

Is there an additional way of achieving that result today?  Or are you
merely saying you really, really, really want one?

You 'cannot get one' today for a number of packages including (according
to one poster here) ClamAV.  So, how are you achieving it _today_, sir?


If you can suggest an additional method, I'll be glad to amend my list
of suggestions.  Otherwise, I'm not sure what your point is.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> Though I suspect no one is going to give you the car you'd like, the 
> devuan developers are solving _his_ problems for him.  The fork is 
> going to help some people.  I suspect there are enough of these people 
> to make the fork worthwhile.  Of course I haven't taken a census, and I 
> don't really know.

Those people are likely to include the guy I shave (yr. humble servant),
so you-plural will have my profound thanks.  And that includes if you
help me get libsystemd0 off my system with minimal effort, which would
be cool even if I don't think it's all that important -- so thanks in
advance!

On the other hand, complaining on mailing lists isn't coding.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Arnt Gulbrandsen  wrote:

> A library can do anything the executable can.

Which is what I thought.
So when someone states that "it's just a library, it doesn't do anything" then 
that needs taking with a pinch of salt because once anything calls one of it's 
functions, then that library can do lots of stuff.
"It wouldn't make sense" for a library to do anything when the main system 
component isn't installed - but don't most of us think that little the systemd 
guys do makes sense anyway ?

So the point I've been making before is that, even if libsystemd0 "does 
nothing" now, we can't be complacent that it won't change. Just imagine if a 
few devs started talking along the lines of "well if systemd isn't installed, 
doing X is a little harder" - I would not be in the least surprised to find 
"stuff to do X" getting shifted from "systemd" to libsystemd0. OK, it's not 
going to be an init system, and I imagine it would be quite hard (or would it 
?) to get a well built daemon running, but is there anything to stop them (say) 
putting all the binary logging stuff in there so devs can use the systemd 
logging instead of using syslog ?
And thus, the presence of libsystemd0 then allows parts of systemd itself to 
pervade non-systemd systems.

OK, this many be paranoia - but I'm sure that was said about the threat of 
systemd when it's inclusion was being considered.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Marlon Nunes]

On 2016-07-28 10:16, Steve Litt wrote:

On Thu, 28 Jul 2016 00:48:12 -0700
Rick Moen  wrote:


Quoting Simon Hobson (li...@thehobsons.co.uk):

> I too did some checking. From practical experience, one of the
> ClamAV packages (IIRC it's clamd) has a hard dependency on
> libsystemd0. Using dpkg --force-depends to install only that
> package without having libsystemd0 installed results in ... it
> failing at startup because it can't open the library.

Out of curiosity, then, what happens if a file exists and can be
opened but isn't libsystemd0?  [Late addendum:  The ClamAV developer
_already gave you a better and cleaner solution_, which you haven't
bothered to mention here.  Any special reason why you omitted that?
I'll fill that in below, in more late-addendum comments.]

Like, find the tiniest lib with fewest functions you can, and cp it
to /lib/[$ARCH]/libsystemd.so.[version] ?

It would be interesting to find whether this package actually _uses_
anything within libsystemd0 -- which would AFAIK be futile if systemd
isn't present -- or whether it merely (a) checks that a library exists
and is openable (dlopen) or whether (b) it looks up symbols/functions
inside the library (dlsym).

One of the ClamAV upstream developers claims it's in effect (a),
saying 'it doesn't do anything if systemd isn't the active init
system'. But you already knew this because the person he said it to
was you.
http://lists.clamav.net/pipermail/clamav-users/2015-June/001592.html

[Late addendum:  And, oh, wait:  The same developer _also_ already
told you that you could make the problem go away by using the
'equivs' trick -- which I have discussed before.
http://lists.clamav.net/pipermail/clamav-users/2015-June/001601.html
So, basically, you're claiming this is a huge unsolvable problem even
though the developer handed you a solution on a platter, that you're
not bothering to mention here.  I see.  Meanwhile, let's go on with
the reply as I originally drafted it:]


If the above test works, and I strongly suspect it would, then it's
probably not hard to come up with smoother and more automatable ways.
However, if I _did_ need package clamav (which I don't), _and_ if I
were feeling paranoid about libsystemd0 (which I don't), then I'd
just grab the package source and rebuild it using the debuild utility
to omit the pointless and annoying library dependency and work around
the packaging bullshit.  And using debuild is not exactly brain
surgery; a link to a page that walks you through that is part of my
OpenRC conversion page.

Please note that I do _not_ assert in any way that it's A Good Thing
that you might be driven to do this (if you are paranoid about
libsystemd0, which I consider a bit irrational).  I'd certainly prefer
if you didn't.  Fortunately, short of that, rebuilding packages
locally is a pretty easy second way.


> I opened a bug, which was very quickly and quite abusively closed as
> "won't fix", and was also told that "it doesn't work like that"
> when I asked if (especially as it was supposedly only one call they
> ever made on non-systemd systems) why they couldn't do "if exists
> libsystemd0 then ..." - something which I now know is possible if
> the dev/packager cares about it.

[Late addendum:  The upstream developer's attitude is annoying, but on
the other hand you also didn't tell the whole truth about your
discussion with him, did you, now?  I also note in passing that you
portrayed this as a problem with the ClamAV 'package', which is a bit
misleading, as the origin of your problem wasn't with a distro
packaging policy but rather upstream.]


> So after all this, I think I see where some of this division comes
> from ...  You *appear* to have been working on the basis that it's a
> "non problem" because the testing you did showed it to be so - for
> your use case.

No, that is _not_ what I said -- and I have said it quite a number of
times and am getting rather tired of having to repeat it.

I perceive it to be not a problem worth spending time on (which is not
the same as 'non problem') because the specific contents of this
library mean it is completely innocuous on a system lacking systemd,
in pretty much exactly the same way that the Kerberos libraries --
pulled in by an essentially bogus library dependency of package
ssh-client on my Kerberos-less system -- are completely innocuous on
a system lacking Kerberos because of their specific contents.

(The self-parodying bullshit objection of 'In the future, horrible
evil things might be put into the library because of horrible evil
package maintainers colluding with horrible evil upstream and the
inability of the entire Linux community to discover what has
happened' has already been addressed upthread.)


> Some of us have been working on the basis that it *is* a problem
> because our testing shows it to be so - for our use cases.

At the risk of speaking a bit sharply for a moment:  Looks to me like
you've also not bothered how to figure 

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[info at smallinnovations.nl]

On 28-07-16 11:33, Rick Moen wrote:


'Building custom packages' is a rather inventively melodramatic
exaggeration of auto-rebuilding a .deb with one spurious lib dependency
disabled, and the 'live grenade' imagery in that specific context is
patently ridiculous.

But hey, if you'd rather sit on your tochis and wait for someone else to
do it for you, I'll not deter you.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


I am a sysadmin myself and why in hell would i like to rebuild local 
packages? I simply want a distro without systemd.


When i cannot get one i will start pinning or rebuild local packages but 
not one moment earlier. And I am quite comfortable with one of the BSD's 
too so it will take a very long time before that to happen.


Grtz.

Nick

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Hendrik Boom]

On Thu, Jul 28, 2016 at 02:33:31AM -0700, Rick Moen wrote:
> 
> But I'm getting the vibes that you are uninterested in 'overcoming
> dependency obstacles' through local system administration.  You'd rather 
> that someone else solves your problem.
> 
> I understand.  I'd like someone else to solve _my_ problems, too.  And
> I'd also like a Caterham, by the way.  (British Racing Green, like
> Patrick McGoohan's Lotus Super 7.  One of the ones with a Ford Zetec
> 1.4L engine is perfectly fine.  Right-hand drive is also fine; I'll
> sweet-talk the automotive grand panjandrums into letting me use it.)

Though I suspect no one is going to give you the car you'd like, the 
devuan developers are solving _his_ problems for him.  The fork is 
going to help some people.  I suspect there are enough of these people 
to make the fork worthwhile.  Of course I haven't taken a census, and I 
don't really know.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Steve Litt  wrote:

> Which brings us full circle. Simon doesn't want to keep playing these
> games, wondering what kind of workaround he'll need next, as Lennart
> decides to subsume yet another Linux functionality, or Debian's "DDs"
> make yet another poor decision on dependencies. So he chose to go with
> the fork.
> 
> I don't have the tech chops to know all the various ways Lennart can
> screw up my life, nor do I have the technical chops to know (without
> huge experimentation) how to work around Lennart's latest incursion. I
> know the incursions will keep on coming, so why in the world would I
> subject myself to them? Therefore, to my limited ability, I help the
> guys who made the fork, and recommend the fork to those not compatible
> with Void or Funtoo or PC-BSD (and most Linux users aren't compatible
> with those).

What he said :-)   ^^^

> And then there's this: I don't know anything about Simon's feelings,
> but Debian's actions of 2014 disgust me. For me, continuing to use
> Debian is an impossibility. Stupid technology comes and goes, but
> betrayal is forever. They got arrogant, they got forked, and the
> resulting Devuan community is one of the best I've ever belonged to.

And that. Except it's not so much disgust, but disappointment - that a distro 
which had such high regard should allow itself to be dragged down this route.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Steve Litt]

On Thu, 28 Jul 2016 00:48:12 -0700
Rick Moen  wrote:

> Quoting Simon Hobson (li...@thehobsons.co.uk):
> 
> > I too did some checking. From practical experience, one of the
> > ClamAV packages (IIRC it's clamd) has a hard dependency on
> > libsystemd0. Using dpkg --force-depends to install only that
> > package without having libsystemd0 installed results in ... it
> > failing at startup because it can't open the library.  
> 
> Out of curiosity, then, what happens if a file exists and can be
> opened but isn't libsystemd0?  [Late addendum:  The ClamAV developer 
> _already gave you a better and cleaner solution_, which you haven't
> bothered to mention here.  Any special reason why you omitted that?
> I'll fill that in below, in more late-addendum comments.]
> 
> Like, find the tiniest lib with fewest functions you can, and cp it
> to /lib/[$ARCH]/libsystemd.so.[version] ?  
> 
> It would be interesting to find whether this package actually _uses_
> anything within libsystemd0 -- which would AFAIK be futile if systemd
> isn't present -- or whether it merely (a) checks that a library exists
> and is openable (dlopen) or whether (b) it looks up symbols/functions
> inside the library (dlsym).
> 
> One of the ClamAV upstream developers claims it's in effect (a),
> saying 'it doesn't do anything if systemd isn't the active init
> system'. But you already knew this because the person he said it to
> was you.
> http://lists.clamav.net/pipermail/clamav-users/2015-June/001592.html
> 
> [Late addendum:  And, oh, wait:  The same developer _also_ already
> told you that you could make the problem go away by using the
> 'equivs' trick -- which I have discussed before.
> http://lists.clamav.net/pipermail/clamav-users/2015-June/001601.html 
> So, basically, you're claiming this is a huge unsolvable problem even
> though the developer handed you a solution on a platter, that you're
> not bothering to mention here.  I see.  Meanwhile, let's go on with
> the reply as I originally drafted it:]
> 
> 
> If the above test works, and I strongly suspect it would, then it's
> probably not hard to come up with smoother and more automatable ways. 
> However, if I _did_ need package clamav (which I don't), _and_ if I
> were feeling paranoid about libsystemd0 (which I don't), then I'd
> just grab the package source and rebuild it using the debuild utility
> to omit the pointless and annoying library dependency and work around
> the packaging bullshit.  And using debuild is not exactly brain
> surgery; a link to a page that walks you through that is part of my
> OpenRC conversion page.
> 
> Please note that I do _not_ assert in any way that it's A Good Thing
> that you might be driven to do this (if you are paranoid about
> libsystemd0, which I consider a bit irrational).  I'd certainly prefer
> if you didn't.  Fortunately, short of that, rebuilding packages
> locally is a pretty easy second way.
> 
> 
> > I opened a bug, which was very quickly and quite abusively closed as
> > "won't fix", and was also told that "it doesn't work like that"
> > when I asked if (especially as it was supposedly only one call they
> > ever made on non-systemd systems) why they couldn't do "if exists
> > libsystemd0 then ..." - something which I now know is possible if
> > the dev/packager cares about it.  
> 
> [Late addendum:  The upstream developer's attitude is annoying, but on
> the other hand you also didn't tell the whole truth about your
> discussion with him, did you, now?  I also note in passing that you
> portrayed this as a problem with the ClamAV 'package', which is a bit
> misleading, as the origin of your problem wasn't with a distro
> packaging policy but rather upstream.]
> 
> 
> > So after all this, I think I see where some of this division comes
> > from ...  You *appear* to have been working on the basis that it's a
> > "non problem" because the testing you did showed it to be so - for
> > your use case.  
> 
> No, that is _not_ what I said -- and I have said it quite a number of
> times and am getting rather tired of having to repeat it.
> 
> I perceive it to be not a problem worth spending time on (which is not
> the same as 'non problem') because the specific contents of this
> library mean it is completely innocuous on a system lacking systemd,
> in pretty much exactly the same way that the Kerberos libraries --
> pulled in by an essentially bogus library dependency of package
> ssh-client on my Kerberos-less system -- are completely innocuous on
> a system lacking Kerberos because of their specific contents.
> 
> (The self-parodying bullshit objection of 'In the future, horrible
> evil things might be put into the library because of horrible evil
> package maintainers colluding with horrible evil upstream and the
> inability of the entire Linux community to discover what has
> happened' has already been addressed upthread.)
> 
> 
> > Some of us have been working on the basis that it *is* a problem
> > because 

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> OK, to start with, "sysadmin" is only a small part of ${dayjob} - so
> many things which full time admins may consider "simple" are not thing
> that I've ever had the time (and generally need) to deal with. I've
> never claimed to be a particularly experienced admin, even if my
> colleagues consider me some sort of guru (everything is relative).

I'm sure you're fine.  

The point is, though, there are some quite simple aspects of running any
deb-based system, including ones I mentioned at least in passing in my
OpenRC Conversion essay, that I hope you will find useful in, among
other things (as the subheader puts it), 'Overcoming Dependency
Obstacles'.

If you'd rather not, that's fine by me, but I notice that just
complaining on mailing lists has done rather little, and maybe some,
y'know, work using fairly basic Linux technology might do more.  

> But the main thing is, a big part of using a packaged system is to
> make things "simpler".

So, complain on mailing lists, then?  ;->



> The moment anyone starts building custom packages then you've tossed a
> live grenade in the system with a tripwire on the pin.

'Building custom packages' is a rather inventively melodramatic
exaggeration of auto-rebuilding a .deb with one spurious lib dependency
disabled, and the 'live grenade' imagery in that specific context is
patently ridiculous.

But hey, if you'd rather sit on your tochis and wait for someone else to
do it for you, I'll not deter you.


> I did look at equivs - but the information (or links) presented to me
> then implied something very different to the "simple" stuff that's
> been presented (IIRC) in this thread.

Your phrase 'the information (or links) presented to me' is
meaninglessly vague.  Some people here seem to do that a lot, I notice.

http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html
walks through a specific case, and is pretty much by the numbers.  I
have no idea what you looked at, but either you didn't bother to start
with the above (which is the link from my essay), or you have IMO rather
extreme hopes and expectations.  With which, I will hasten to add, I
would still wish you all the best.


> Then (from what I vaguely recall reading) I was under the impression
> that equivs involved more than just a "pretend that this package is
> installed" instruction to apt as the recent reference here suggested
> to me. But from empirical observation, just telling apt to "pretend
> libsystemd0 is installed even though it isn't" won't work when the
> program "blows up" during startup when the linker can't open a library
> it's been told is needed by this program.

The upstream ClamAV developer _asserted_ that exactly that would work.
So, was he correct in so saying, or was he incorrect?  Did it ever 
occur to you to check?  No?  Why not?  Allergic to empiricism?  Broken
thumbs?  Highly selective phobias?  Cat dragged off your computer?

Personally, in your shoes -- if I had an irrational paranoia about
libsystemd0, which I currently do not -- I would want to know.  Wanting
to know, I would indulge my personal affection for empiricism.  E.g.,
when the relevant question is 'Is $FOO true?', I would investigate $FOO.

If the upstream ClamAV developer's assertion is incorrect, then the
other (rather obvious, I thought) trick I mentioned would be extremely
likely to suffice in its place.

But I'm getting the vibes that you are uninterested in 'overcoming
dependency obstacles' through local system administration.  You'd rather 
that someone else solves your problem.

I understand.  I'd like someone else to solve _my_ problems, too.  And
I'd also like a Caterham, by the way.  (British Racing Green, like
Patrick McGoohan's Lotus Super 7.  One of the ones with a Ford Zetec
1.4L engine is perfectly fine.  Right-hand drive is also fine; I'll
sweet-talk the automotive grand panjandrums into letting me use it.)


> So look at it from my PoV.

When I'm done looking at it from my own, sure.  You might have to wait a
few decades, though.  I believe I still have some miles left on my
warranty.  ;->

Looking at it from my own, I see that I've documented ways to deal
overcome dependency obstacles, but you don't want to do them.  Fair
dinkum, as the Aussies say.  You aren't obliged.  But I _did_ provide
them.



> Incidentally, after the exchange referred to, someone contacted me
> offlist with the comment "if that's the customer service department,
> I'd hate to see the complaints department" - so it would appear at one
> other person sees my PoV.

That was on-list.  It's about four posts down the archived thread.
Whose link I provided.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/28/2016 05:50 PM, Simon Hobson wrote:
...

but personally I consider it unethical to leave booby traps in systems for 
anyone that comes along to manage it after me.

...
> That, for the most part, is why I've gone to great lengths to only 
use distro packaged software on the systems - even when it would have 
been easier at times (thinking more about CGI stuff rather than compiled 
programs) to grab the upstream and manually install it.

...

Good man!

Some of the best paying (read: stressful) jobs I've done were figuring 
out some custom system and port it over to something 
standard/out-of-the-box/maintainable.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

> If the above test works, and I strongly suspect it would, then it's
> probably not hard to come up with smoother and more automatable ways. 
> However, if I _did_ need package clamav (which I don't), _and_ if I were
> feeling paranoid about libsystemd0 (which I don't), then I'd just grab
> the package source and rebuild it using the debuild utility to omit the
> pointless and annoying library dependency and work around the packaging
> bullshit.  And using debuild is not exactly brain surgery; a link to a
> page that walks you through that is part of my OpenRC conversion page.

OK, to start with, "sysadmin" is only a small part of ${dayjob} - so many 
things which full time admins may consider "simple" are not thing that I've 
ever had the time (and generally need) to deal with. I've never claimed to be a 
particularly experienced admin, even if my colleagues consider me some sort of 
guru (everything is relative). Similarly, I don't claim to be a programmer (I 
can hack a bit of Bash these days, but that's about it) - even though a 1/4 
century ago I was writing code commercially (in PL/M 51 if you're interested 
https://en.wikipedia.org/wiki/PL/M).


But the main thing is, a big part of using a packaged system is to make things 
"simpler". The moment anyone starts building custom packages then you've tossed 
a live grenade in the system with a tripwire on the pin. So anyone coming along 
to admin these systems after me - whether that's because I've moved on or 
fallen under the proverbial bus - is put in a situation where a simple and 
innocuous operation could "blow up" the system. OK, so it wouldn't be me that 
had to worry about that, but personally I consider it unethical to leave booby 
traps in systems for anyone that comes along to manage it after me. Either I 
fudge with version numbers so that an apt-get upgrade will never try and 
replace my customer package (leaving someone scratching their head as to why), 
or I don't and an apt-get upgrade does strange things (most likely failing with 
misleading errors due to pinning and it not being able to satisfy dependencies).

And I can absolutely 100% guarantee that anyone else in the company that might 
have to take over is a long way off the skillset for things like 
building customer packages, and I do mean a very loong way off that. 
That, for the most part, is why I've gone to great lengths to only use distro 
packaged software on the systems - even when it would have been easier at times 
(thinking more about CGI stuff rather than compiled programs) to grab the 
upstream and manually install it.

I did look at equivs - but the information (or links) presented to me then 
implied something very different to the "simple" stuff that's been presented 
(IIRC) in this thread. Then (from what I vaguely recall reading) I was under 
the impression that equivs involved more than just a "pretend that this package 
is installed" instruction to apt as the recent reference here suggested to me. 
But from empirical observation, just telling apt to "pretend libsystemd0 is 
installed even though it isn't" won't work when the program "blows up" during 
startup when the linker can't open a library it's been told is needed by this 
program.


So look at it from my PoV.
I've been told that I could build an equivs package to provide the library and 
empty functions to keep the program happy - and I've been told that equivs is 
just a short recipe to apt that makes it "pretend" the library is installed.
I've been told that no you can't just open the library if it exists, and I've 
been told that it's really easy to do.
I've been told that equivs (as in the latter) will let a program start even if 
the library isn't there, and I've shown by experiment that the program "blows 
up" at start if the library is missing.
Confused :-/


Incidentally, after the exchange referred to, someone contacted me offlist with 
the comment "if that's the customer service department, I'd hate to see the 
complaints department" - so it would appear at one other person sees my PoV.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> I too did some checking. From practical experience, one of the ClamAV
> packages (IIRC it's clamd) has a hard dependency on libsystemd0. Using
> dpkg --force-depends to install only that package without having
> libsystemd0 installed results in ... it failing at startup because it
> can't open the library.

Out of curiosity, then, what happens if a file exists and can be opened
but isn't libsystemd0?  [Late addendum:  The ClamAV developer 
_already gave you a better and cleaner solution_, which you haven't
bothered to mention here.  Any special reason why you omitted that?
I'll fill that in below, in more late-addendum comments.]

Like, find the tiniest lib with fewest functions you can, and cp it to 
/lib/[$ARCH]/libsystemd.so.[version] ?  

It would be interesting to find whether this package actually _uses_
anything within libsystemd0 -- which would AFAIK be futile if systemd
isn't present -- or whether it merely (a) checks that a library exists
and is openable (dlopen) or whether (b) it looks up symbols/functions
inside the library (dlsym).

One of the ClamAV upstream developers claims it's in effect (a), saying
'it doesn't do anything if systemd isn't the active init system'.
But you already knew this because the person he said it to was you.
http://lists.clamav.net/pipermail/clamav-users/2015-June/001592.html

[Late addendum:  And, oh, wait:  The same developer _also_ already told
you that you could make the problem go away by using the 'equivs' trick
-- which I have discussed before.
http://lists.clamav.net/pipermail/clamav-users/2015-June/001601.html 
So, basically, you're claiming this is a huge unsolvable problem even
though the developer handed you a solution on a platter, that you're
not bothering to mention here.  I see.  Meanwhile, let's go on with the
reply as I originally drafted it:]


If the above test works, and I strongly suspect it would, then it's
probably not hard to come up with smoother and more automatable ways. 
However, if I _did_ need package clamav (which I don't), _and_ if I were
feeling paranoid about libsystemd0 (which I don't), then I'd just grab
the package source and rebuild it using the debuild utility to omit the
pointless and annoying library dependency and work around the packaging
bullshit.  And using debuild is not exactly brain surgery; a link to a
page that walks you through that is part of my OpenRC conversion page.

Please note that I do _not_ assert in any way that it's A Good Thing
that you might be driven to do this (if you are paranoid about
libsystemd0, which I consider a bit irrational).  I'd certainly prefer
if you didn't.  Fortunately, short of that, rebuilding packages locally
is a pretty easy second way.


> I opened a bug, which was very quickly and quite abusively closed as
> "won't fix", and was also told that "it doesn't work like that" when I
> asked if (especially as it was supposedly only one call they ever made
> on non-systemd systems) why they couldn't do "if exists libsystemd0
> then ..." - something which I now know is possible if the dev/packager
> cares about it.

[Late addendum:  The upstream developer's attitude is annoying, but on
the other hand you also didn't tell the whole truth about your
discussion with him, did you, now?  I also note in passing that you
portrayed this as a problem with the ClamAV 'package', which is a bit
misleading, as the origin of your problem wasn't with a distro packaging
policy but rather upstream.]


> So after all this, I think I see where some of this division comes
> from ...  You *appear* to have been working on the basis that it's a
> "non problem" because the testing you did showed it to be so - for
> your use case.

No, that is _not_ what I said -- and I have said it quite a number of
times and am getting rather tired of having to repeat it.

I perceive it to be not a problem worth spending time on (which is not
the same as 'non problem') because the specific contents of this library
mean it is completely innocuous on a system lacking systemd, in pretty
much exactly the same way that the Kerberos libraries -- pulled in by an
essentially bogus library dependency of package ssh-client on my
Kerberos-less system -- are completely innocuous on a system lacking
Kerberos because of their specific contents.

(The self-parodying bullshit objection of 'In the future, horrible evil
things might be put into the library because of horrible evil package
maintainers colluding with horrible evil upstream and the inability of
the entire Linux community to discover what has happened' has already
been addressed upthread.)


> Some of us have been working on the basis that it *is* a problem
> because our testing shows it to be so - for our use cases.

At the risk of speaking a bit sharply for a moment:  Looks to me like
you've also not bothered how to figure out how to do basic
distro-centric system administration.  If you'd like to learn a bit of
that, my OpenRC 

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

> I have a better question:  Is there something about empiricism that many
> people on this mailing list cannot cope with?
> 
> Back when I had newly joined this mailing list and all of these idle
> allegations and rhetorical questions started being posted, I decided to
> do that thing  What's it called?  Oh, right:  'Checking.'

I too did some checking. From practical experience, one of the ClamAV packages 
(IIRC it's clamd) has a hard dependency on libsystemd0. Using dpkg 
--force-depends to install only that package without having libsystemd0 
installed results in ... it failing at startup because it can't open the 
library.

I opened a bug, which was very quickly and quite abusively closed as "won't 
fix", and was also told that "it doesn't work like that" when I asked if 
(especially as it was supposedly only one call they ever made on non-systemd 
systems) why they couldn't do "if exists libsystemd0 then ..." - something 
which I now know is possible if the dev/packager cares about it.


So after all this, I think I see where some of this division comes from ...
You *appear* to have been working on the basis that it's a "non problem" 
because the testing you did showed it to be so - for your use case. Some of us 
have been working on the basis that it *is* a problem because our testing shows 
it to be so - for our use cases. And we've all failed to pick up on this - a 
bit like the tory of the blind men and the elephant  
https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Arnt Karlsen]

On Wed, 27 Jul 2016 16:23:46 -0700, Rick wrote in message 
<20160727232346.gh10...@linuxmafia.com>:

> Quoting Arnt Karlsen (a...@iaksess.no):
> 
> > ..re-running your tests now, do you still get the same results 
> > now, as back then when you first checked?  
> 
> 
> root@mini:/tmp# cd /lib/x86_64-linux-gnu/
> root@mini:/lib/x86_64-linux-gnu# chmod 000 libsystemd.so.0.3.1 
> root@mini:/lib/x86_64-linux-gnu# rc-service apache2 start
> [] Starting Apache httpd web server: apache2AH00558: apache2:
> Could not reliably determine the server's fully qualified domain
> name, using 127.0.0.1. Set the 'ServerName' directive globally to
> suppress this message . ok root@mini:/lib/x86_64-linux-gnu#
> cd /var/log/apache2/ root@mini: /var/log/apache2# ls -l total 4
> -rw-r- 1 root adm   0 Jul 27 16:05 access.log
> -rw-r- 1 root adm 279 Jul 27 16:11 error.log
> -rw-r- 1 root adm   0 Jul 27 16:05 other_vhosts_access.log
> root@mini:/var/log/apache2# cat error.log 
> [Wed Jul 27 16:11:07.683444 2016] [mpm_event:notice] [pid 4687:tid
> 140400470632320] AH00489: Apache/2.4.23 (Debian) configured --
> resuming normal operations [Wed Jul 27 16:11:07.683444 2016]
> [core:notice] [pid 4687:tid 140400470632320] AH00094: Command line:
> '/usr/sbin/apache2' root@mini:/var/log/apache2# exit
> 
> 
> That's from a GNU script 'typescript' session log file, so I've done a
> bit of touchup to remove control characters and similar spurious
> artifiacts, session-logging of my typoes, and that sort of thing.
> 
> Default index page loads using lynx. 
> 
> This is just a smoke-test, of course; I'm sure much more elaborate
> testing would be possible if I pondered this for a while, and I
> vaguely recall doing more the first time but can't remember exactly
> what.

..aye, the perils of not keeping records of what you did. ;o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Arnt Karlsen (a...@iaksess.no):

> ..re-running your tests now, do you still get the same results 
> now, as back then when you first checked?  


root@mini:/tmp# cd /lib/x86_64-linux-gnu/
root@mini:/lib/x86_64-linux-gnu# chmod 000 libsystemd.so.0.3.1 
root@mini:/lib/x86_64-linux-gnu# rc-service apache2 start
[] Starting Apache httpd web server: apache2AH00558: apache2: Could not 
reliably determine the server's fully qualified domain name, using 127.0.0.1. 
Set the 'ServerName' directive globally to suppress this message
. ok
root@mini:/lib/x86_64-linux-gnu# cd /var/log/apache2/
root@mini: /var/log/apache2# ls -l
total 4
-rw-r- 1 root adm   0 Jul 27 16:05 access.log
-rw-r- 1 root adm 279 Jul 27 16:11 error.log
-rw-r- 1 root adm   0 Jul 27 16:05 other_vhosts_access.log
root@mini:/var/log/apache2# cat error.log 
[Wed Jul 27 16:11:07.683444 2016] [mpm_event:notice] [pid 4687:tid 
140400470632320] AH00489: Apache/2.4.23 (Debian) configured -- resuming normal 
operations
[Wed Jul 27 16:11:07.683444 2016] [core:notice] [pid 4687:tid 140400470632320] 
AH00094: Command line: '/usr/sbin/apache2'
root@mini:/var/log/apache2# exit


That's from a GNU script 'typescript' session log file, so I've done a
bit of touchup to remove control characters and similar spurious
artifiacts, session-logging of my typoes, and that sort of thing.

Default index page loads using lynx. 

This is just a smoke-test, of course; I'm sure much more elaborate
testing would be possible if I pondered this for a while, and I vaguely
recall doing more the first time but can't remember exactly what.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Arnt Karlsen]

On Wed, 27 Jul 2016 13:17:40 -0700, Rick wrote in message 
<20160727201740.gf10...@linuxmafia.com>:

> Quoting Simon Hobson (li...@thehobsons.co.uk):
> 
> > And won't you then find that all those packages with gratuitous
> > libsystemd0 dependencies will stop working ?
> 
> I have a better question:  Is there something about empiricism that
> many people on this mailing list cannot cope with?
> 
> Back when I had newly joined this mailing list and all of these idle
> allegations and rhetorical questions started being posted, I decided
> to do that thing  What's it called?  Oh, right:  'Checking.'
> 
> I did a quick smoke test on my test VM by chmod'ing
> /lib/x86_64-linux-gnu/libsystemd.so.0.3.1 to 000, starting Apache,
> making sure it appeared to work OK, and skimming its logs looking for
> anything amiss.  Nothing wrong that I was able to see.
> 
> If I ever get to worrying about this in production after attending to
> all the myriad _real_ concerns I have, I suppose I'd more-carefully
> check various things that might have screwy problem and might not.
> Meanwhile, I also would expect none, simply on grounds of the known
> facts of what's in the damned thing.
> 
> Now, you guys presumably all have Linux systems.  Why pose the
> question? Why not just check, if you want to know?

..re-running your tests now, do you still get the same results 
now, as back then when you first checked?  

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Dave Turner]

On 27/07/16 21:21, Rick Moen wrote:

Quoting Rainer Weikusat (rweiku...@talktalk.net):


these are obviously not identical: The subjects differ.

I repeat:  I really did not understand what you were saying, and I still
don't.  Therefore, I summarised my best guess, apologised for probably
being dense and overly fond of the specific and concrete, and attempted
to suggest giving up said discussion, especially given that mostly you
seemed to be devoted to finding fault with me personally.  Is there some
reason this is not a good idea?  I continue to think it is.


I'm bored with this. I don't care. Stop it.

As soon as I have finished my current Android project using my main 
laptop running debian sid anything that has 'systemd' as part of its 
name goes. And that will mean goodbye to debian, hopefully hello devuan, 
but there's all those BSDs out there...


DaveT - looking forward to a weekend spent converting the Harley from 
EFI to carb.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Rainer Weikusat (rweiku...@talktalk.net):

> these are obviously not identical: The subjects differ.

I repeat:  I really did not understand what you were saying, and I still
don't.  Therefore, I summarised my best guess, apologised for probably
being dense and overly fond of the specific and concrete, and attempted
to suggest giving up said discussion, especially given that mostly you
seemed to be devoted to finding fault with me personally.  Is there some
reason this is not a good idea?  I continue to think it is.

-- 
Cheers, Saturday night in Toledo, Ohio
Rick Moen   Is like being nowhere at all.
r...@linuxmafia.com All through the day as the hours rush by
youtube.com/watch?v=XZUGSSYlPYI You sit in the park and you watch the grass die.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> And won't you then find that all those packages with gratuitous
> libsystemd0 dependencies will stop working ?

I have a better question:  Is there something about empiricism that many
people on this mailing list cannot cope with?

Back when I had newly joined this mailing list and all of these idle
allegations and rhetorical questions started being posted, I decided to
do that thing  What's it called?  Oh, right:  'Checking.'

I did a quick smoke test on my test VM by chmod'ing
/lib/x86_64-linux-gnu/libsystemd.so.0.3.1 to 000, starting Apache,
making sure it appeared to work OK, and skimming its logs looking for
anything amiss.  Nothing wrong that I was able to see.

If I ever get to worrying about this in production after attending to
all the myriad _real_ concerns I have, I suppose I'd more-carefully
check various things that might have screwy problem and might not.
Meanwhile, I also would expect none, simply on grounds of the known
facts of what's in the damned thing.

Now, you guys presumably all have Linux systems.  Why pose the question?
Why not just check, if you want to know?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rainer Weikusat]

Hendrik Boom  writes:
> On Wed, Jul 27, 2016 at 10:34:55AM -0700, Rick Moen wrote:
>> By the way, what specifically does 'entangle it with unwanted
>> systemd-isms' actually _mean_, and what does that have to do with
>> whatever-the-heck-it-was that Rainier said?  Once again, it seems to me,
>> there's vagueness in unfortunate parts of this narrative.
>
> It obviousy depends on what is wanted and what is not wanted.  That 
> depends on the user and system administrator. 

libsystemd on its own doesn't entangle anyhting with anything else as
it's just a runtime link library providing systemd API symbols (as I've
written quite a few times already). But its presence enables people to
'entangle' unrelated applications (like apache) with systemd-specific
function calls (of no use to anyone but systemd users): Weren't it for
libsystemd, UNIX(*) application which were 'enhanced' with systemd API
calls like sd_notify wouldn't run on systems without systemd anymore.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting dev (devua...@gmail.com):

> On systems where security and stability are important, needless
> dependencies and pointless software expose a broader attack surface.

Generically, yes.

I definitely always appreciate having less unwanted code on my system,
particularly code that ever runs with elevated privilege.  Short of
Gentoo-style local building of packages and tweaking build options, it's
non-trivial to do that, though.  

I've covered a couple of the ways to do that.  If you have practical
suggestions rather than just vague philophising, I'm still waiting to
hear them.

> On server systems, it's considered best practice to install the
> minimal amount of software needed for the running services, and no
> more.

You're aware that I'm a sysadmin, right?  Just checking.

> Historically speaking, most Linux distros easily strip-down this
> way.

Yeah, right.  Thus the Kerberos libraries for /usr/bin/ssh.  *headdesk*

> Systemd seems well on it's way to reverse that. I would say
> that is most certainly of "particular importance"

We weren't talking about that, though, only libsystemd0.

(Seriously, guys, you do need to FAQ that.)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

> ... then I'll be replacing libsystemd0 with an 'equivs'
> recipe about two minutes later.

And won't you then find that all those packages with gratuitous libsystemd0 
dependencies will stop working ?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Hendrik Boom]

On Wed, Jul 27, 2016 at 10:34:55AM -0700, Rick Moen wrote:
> 
> By the way, what specifically does 'entangle it with unwanted
> systemd-isms' actually _mean_, and what does that have to do with
> whatever-the-heck-it-was that Rainier said?  Once again, it seems to me,
> there's vagueness in unfortunate parts of this narrative.

It obviousy depends on what is wanted and what is not wanted.  That 
depends on the user and system administrator. 

-- hendrik


> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rainer Weikusat]

Hendrik Boom  writes:
> On Tue, Jul 26, 2016 at 11:01:04AM -0700, Rick Moen wrote:
>> Quoting Rainer Weikusat (rweiku...@talktalk.net):
>> > Rick Moen  writes:
>> > > Quoting Rainer Weikusat (rweiku...@talktalk.net):
>> > >
>> > >> To re-iterate this: 
>> > >
>> > > [more very strangely worded, difficult-to-parse prose, seemingly alleging
>> > > that library libsystemd0 can be used to insert 'calls' into unrelated
>> > > applications -- which assertion in my view does not seem correct, if I
>> > > am parsing this odd claim correctly]
>> > >
>> > >> I honestly understand why stating this as it is causes hostile
>> > >> reactions.
>> > >
>> > > I cannot recall having said anything hostile to you,
>> > 
>> > Replacing
>> > 
>> >Because of libsystemd, a systemd sub-project, technically
>> >gratuitious calls to systemd-specific functions
>> >can be inserted into unrelated applications. [as it provides the
>> >required symbols]
>> > 
>> > with
>> > 
>> >libsystemd can be used to insert 'calls' into unrelated
>> >applications
>> > 
>> > won't win you any prices for objectivity.
>> > 
>> > But this kind of 'discussion' is as tiresome as it is useless.
>> 
>> Rainer, I did not, and do not, understand how the mere presence of
>> libsystemd0 can insert 'calls to systemd-specific functions' 
>> into related applications.  
>
> Once again, it is a matter of trust, not technical content.  Do you 
> trust the maintainers of libsystemd0 not to entangle it with unwanted 
> systemd-isms?  You evidently do.  Rainer does not.

If you look at simplified, abstracted version of my sentence, you'll
note that it basically says

X enables Y to do Z

while Moen's sentence is

X does Z

these are obviously not identical: The subjects differ.





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> Once again, it is a matter of trust, not technical content.  Do you 
> trust the maintainers of libsystemd0 not to entangle it with unwanted 
> systemd-isms?  You evidently do.  Rainer does not.

I'm certainly willing to consider the possibility that the upstream
coders are evil _and_ the package maintainers are evil _and_ that nobody
I read including the entire brain trust of LWN.net can figure that out
and tell me.

If those two extremely coincidentally evil parties collaborate _and_
everyone completely fails to notice, then I'm indeed in trouble.  If
those two extremely coincidentally evil parties collaborate and someone
_does_ notice, then I'll be replacing libsystemd0 with an 'equivs'
recipe about two minutes later.

Incidentally, if both extremely coincidentally evil parties collaborate 
and nobody notices, I am probably in trouble on far more significant
matters than libsystemd0, and I'd have extremely just cause to start
getting deeply paranoid about every single one of the...

 $ dpkg -l | grep '^ii' | wc -l
685
 $

...685 package on my server, all of which would suddenly become very
threatening.

If your point is merely that one ends up bestowing (conditional) trust
onto the developers of all distro packages one runs, that is true but
banal and obvious.  If you wish to assert that I have some particular
and pronounced reason I should distrust a distro packager of libssytemd0
_and_ that the entire Linux community would utterly fail to notice this
betrayal, I have yet to hear it, and wait with polite anticipation (but
I'm not holding my breath waiting).

By the way, what specifically does 'entangle it with unwanted
systemd-isms' actually _mean_, and what does that have to do with
whatever-the-heck-it-was that Rainier said?  Once again, it seems to me,
there's vagueness in unfortunate parts of this narrative.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[dev]

On 07/26/2016 12:37 PM, Rick Moen wrote:


It _was_ indeed an unnecessary build dependency.


Precisely my point. A point which could be made about systemd in 
general: A lot of unnecessary.




agree that it's 'problematic' in the sense that I'd rather not have it
on my systems, but it's not of particular importance.


On systems where security and stability are important, needless 
dependencies and pointless software expose a broader attack surface. On 
server systems, it's considered best practice to install the minimal 
amount of software needed for the running services, and no more.


Historically speaking, most Linux distros easily strip-down this way. 
Systemd seems well on it's way to reverse that. I would say that is most 
certainly of "particular importance"

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Hendrik Boom]

On Tue, Jul 26, 2016 at 11:01:04AM -0700, Rick Moen wrote:
> Quoting Rainer Weikusat (rweiku...@talktalk.net):
> 
> > Rick Moen  writes:
> > > Quoting Rainer Weikusat (rweiku...@talktalk.net):
> > >
> > >> To re-iterate this: 
> > >
> > > [more very strangely worded, difficult-to-parse prose, seemingly alleging
> > > that library libsystemd0 can be used to insert 'calls' into unrelated
> > > applications -- which assertion in my view does not seem correct, if I
> > > am parsing this odd claim correctly]
> > >
> > >> I honestly understand why stating this as it is causes hostile
> > >> reactions.
> > >
> > > I cannot recall having said anything hostile to you,
> > 
> > Replacing
> > 
> > Because of libsystemd, a systemd sub-project, technically
> > gratuitious calls to systemd-specific functions
> > can be inserted into unrelated applications. [as it provides the
> > required symbols]
> > 
> > with
> > 
> > libsystemd can be used to insert 'calls' into unrelated
> > applications
> > 
> > won't win you any prices for objectivity.
> > 
> > But this kind of 'discussion' is as tiresome as it is useless.
> 
> Rainer, I did not, and do not, understand how the mere presence of
> libsystemd0 can insert 'calls to systemd-specific functions' 
> into related applications.  

Once again, it is a matter of trust, not technical content.  Do you 
trust the maintainers of libsystemd0 not to entangle it with unwanted 
systemd-isms?  You evidently do.  Rainer does not.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Didier Kryn]

Le 26/07/2016 13:28, fsmithred a écrit :

On 07/25/2016 06:09 PM, Didier Kryn wrote:

Le 25/07/2016 23:35, fsmithred a écrit :

Either way, it
looks like libsystemd is passively providing code for something else to
use.

 Calling a function does not mean that this function passively provides
code to the caller. What happens  is (simplified) the program counter (the
address from which instructions are fetched) jumps to the called function,
and, when the function has finished execution (encountering the return
instruction, returns to the caller, just one instruction after the initial
jump.

 Didier



Thanks. I had to read that a few times before it sunk in, but it makes
sense, and it's consistent with what I know about shell programming.




It is just about the concept of active or passive things. One could 
say the only active thing in the computer is, to simplify, the processor 
cores. In that sense all instructions are passive, wether they are in 
the main program or in a subprogram and wether this subprogram belongs 
to a static or dynamic library does not change it.


But it is a common shortcut to speak of instruction as if *they* do 
something, and, in that sense also, it is the same if they belong to a 
subprogram.


People working on compilers, linkers and that sort of things refer 
to the machine instructions as "text". I think it is because it is the 
text read and executed by the cpu, a text written in the language of the 
cpu.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rainer Weikusat]

Didier Kryn  writes:
> Le 25/07/2016 23:35, fsmithred a écrit :
>> Either way, it
>> looks like libsystemd is passively providing code for something else to
>> use.
> Calling a function does not mean that this function passively
> provides code to the caller.

But the library does that (or at least, that's how its function could be
described). After compiling the following program,


#include 

int main(void)
{
puts("Hello?");
return 0;
}
-

the resulting ELF binary records the name of the C library in its
DT_NEEDED section,

[rw@doppelsaurus]/tmp#objdump -p a.out | grep NEEDED
  NEEDED   libc.so.6

and its symbol table contains an 'undefined' entry for puts

[rw@doppelsaurus]/tmp#objdump --syms a.out | grep puts  
   F *UND*    puts@@GLIBC_2.2.5

When starting the program, the dynamic linker loads the needed libraries
and then tries to resolve any undefind symbols:

[rw@doppelsaurus]/tmp#LD_DEBUG=libs,symbols,bindings ./a.out  2>&1

  3922: find library=libc.so.6 [0]; searching
  3922:  search cache=/etc/ld.so.cache
  3922:   trying file=/lib/x86_64-linux-gnu/libc.so.6

[...]

  3922: symbol=puts;  lookup in file=./a.out [0]
  3922: symbol=puts;  lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0]
  3922: binding file ./a.out [0] to /lib/x86_64-linux-gnu/libc.so.6 
[0]: normal symbol `puts' [GLIBC_2.2.5]

This means in order to start the program, both the library file and the
actual symbol definition is needed. The dynamic symbol table of the
library provides the address of the entry point in the function,

[rw@doppelsaurus]/tmp#objdump -T /lib/x86_64-linux-gnu/libc.so.6  | grep puts
00068e90 gDF .text  01b2  GLIBC_2.2.5 _IO_puts
00068e90  w   DF .text  01b2  GLIBC_2.2.5 puts

And this address is then used to 'connect' calls made by the program to
the code provided by the library. The code of the function can be found
by running

objdump -d /lib/x86_64-linux-gnu/libc.so.6  | less

and searching for address recorded in the dynamic symbol table (with
leading zeroes omitted, ie, 68e90).

> What happens  is (simplified) the program
> counter (the address from which instructions are fetched) jumps to the
> called function, and, when the function has finished execution
> (encountering the return instruction, returns to the caller, just one
> instruction after the initial jump.

This is what happens after the program was started if a from the library
is actually called. The following program

--
#include 

int main(void)
{
printf("%p\n", puts);
return 0;
}
---

uses the puts symbol without calling the function.

A program may also load a library (shared object, actually) at run time
and perform all these steps with explictly written code instead of
relying on the dynamic linker (containing similar code).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Edward Bartolo]

dev wrote:
<<
It seems I cannot have a functioning Apache system on Debian 8 without
installing at least some minimal facet of systemd and that's
problematic if not for any other reason than simply being an
unnecesary dependency. What this all really illustrates is the
insidious nature of systemd assimilation and how far things have gone,
and how far they will continue to go.
>>

SystemD is an "excuse", disguised as progress, to replace most of GNU
software, by assuming the interests of a portion of desktop users,
should come first.

This is one reason that explains what is causing the creep. The other
reason is intentionally making packages dependent on systemd to make
it harder for alternatives to survive.

Grounds tinfoil hat to discharge dangerous voltage levels.

-- 
Those who abuse me will be banned immediately from my email account.
Here, I am communicating with supposedly intelligent adults who are
responsible for their actions.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Walter]

On 07/26/2016 09:58 PM, dev wrote:



On 07/26/2016 04:26 AM, Rick Moen wrote:


libsystemd0's status as a bundle of interface code that does nothing in
the absence of systemd is not because it's a library -- obviously -- but
rather because all it _contains_ is interface code that does nothing in
the absence of systemd


Well now, if that were true, it would not need to be there at all and
the apache common lib could be installed without needing that systemd
dependency. Correct?

It seems I cannot have a functioning Apache system on Debian 8 without
installing at least some minimal facet of systemd and that's problematic
if not for any other reason than simply being an unnecesary dependency.
What this all really illustrates is the insidious nature of systemd
assimilation and how far things have gone, and how far they will
continue to go.

Systemd isn't going to stop at just init. There are far to many
opportunities to embrace, extend and extinguish entire distributions.



You are not kidding me? Is that because of mod_systemd?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[fsmithred]

On 07/25/2016 06:09 PM, Didier Kryn wrote:
> Le 25/07/2016 23:35, fsmithred a écrit :
>> Either way, it
>> looks like libsystemd is passively providing code for something else to
>> use.
> Calling a function does not mean that this function passively provides
> code to the caller. What happens  is (simplified) the program counter (the
> address from which instructions are fetched) jumps to the called function,
> and, when the function has finished execution (encountering the return
> instruction, returns to the caller, just one instruction after the initial
> jump.
> 
> Didier
> 


Thanks. I had to read that a few times before it sunk in, but it makes
sense, and it's consistent with what I know about shell programming.

-fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[fsmithred]

On 07/25/2016 05:57 PM, Rick Moen wrote:

> If you ever feel like trying a less-brittle Desktop Environment ('DE'),
> consider LXQt or Enlightenment.  (A more-radical step would be no DE at
> all, which is my personal preference.  To me, a DE is a goulash of apps I
> want with ones I don't, so I see no value in the ensemble.  But as 
> Prince Orlovsky said in 'Die Fledermaus', Chacun à son goût:
> https://www.youtube.com/watch?v=l6uEmtn56M0 )
> 


I did try both of those, and we clearly have different tastes. My first
impressions of LXQt are that it's as pretty as IceWM (pretty ugly) at
twice the ram, but at least it has graphical configuration tools that are
easy to find. I know it's still young, so I've promised to give it another
chance. I liked lxde and used it for a while.

There was an early version of Refracta that had e-17 on Lenny (before I
inherited the project.) I was impressed with how much it could do with so
little. I even pulled some memory sticks out of the computer to see how
small it could get, and I was able to operate the desktop with terminal,
file manager and text editor with only 64MB.

The first systemd-free version of Refracta had openbox with lxpanel and
spacefm. I could see going back to that, but I have to answer to users,
and it looks like we're sticking with xfce for the time being. It really
is quite workable and should not be put in the same category as Gnome or
KDE. I don't have the patience (or hardware resources) for those two.


-fsr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

>> OK, that's what I thought, which is at odds with some comments that have 
>> been made.
> 
> Well, if you're referring to 'comments that have been made' about
> libsystemd0, the more useful (IMO) comments characterised what is
> actually present in that library, that it contains just interface code
> that absent systemd does[1] nothing

And you've gone on to keep extrapolating that "that's all a library does".

I have not at any point disputed that that may be all it does now - yes you 
persist in wording your replies in a manner which (whether deliberate or not) 
implies that all such a library can do is "nothing".

Now lets settle this once and for all, the thing is that this is supposed to be 
about choice. I really don't care whether you are happy or not having 
libsystemd0 on your system - that's your choice, based on your priorities, 
policies, etc, etc.

It is *MY* choice that I don't want it on my systems. It's not just the "what 
could they slip in" bit - there are a number of more philosophical reasons. I 
really don't care if *YOU* think it's paranoid - it's *MY* choice (which 
happens to be shared by others). Please respect that, because your tone 
throughout this thread suggests that you don't respect that.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Didier Kryn]

Le 25/07/2016 23:35, fsmithred a écrit :

Either way, it
looks like libsystemd is passively providing code for something else to
use.
Calling a function does not mean that this function passively 
provides code to the caller. What happens  is (simplified) the program 
counter (the address from which instructions are fetched) jumps to the 
called function, and, when the function has finished execution 
(encountering the return instruction, returns to the caller, just one 
instruction after the initial jump.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting fsmithred (fsmith...@gmail.com):

> Yeah, that was me, and it was based on partially incorrect testing. I set
> the permissions to 000 on the wrong target. The test with the dummy
> libsystemd0 package worked great to fulfill the package dependency and
> allowed me to install gvfs, but gvfs wouldn't make the drive icons.
> 
> I repeated the permissions test on the correct target with the real
> libsystemd (chmod 000 /lib/i386-linux-gnu/libsystemd.so.0.3.1)
> and I got the same result. If libsystemd is not readable, gvfs won't show
> the drive icons.

Let me take a moment to thank you for going to the effort.  I respect 
seeking meaningful data rather than just posting advocacy, so I
appreciate that.  No worries about the mistake; if I had to pay a penny
for every technical mistake or erroneous characterisation I made, I'd be
poor indeed.

> So yes, I agree with you that it looks like it's gvfs that's doing
> something, and the something it's probably doing is using code in
> libsystemd. Or maybe it's telling something else to do it. Either way, it
> looks like libsystemd is passively providing code for something else to
> use. If the code is being used by some program, that's doing something.
> 
> Is there another interpretation of these results?

My guess is and was that gfvs merely checks for existence/nonexistence 
of a function inside gvfs, and does disable/enable based on what it finds.

If you ever feel like trying a less-brittle Desktop Environment ('DE'),
consider LXQt or Enlightenment.  (A more-radical step would be no DE at
all, which is my personal preference.  To me, a DE is a goulash of apps I
want with ones I don't, so I see no value in the ensemble.  But as 
Prince Orlovsky said in 'Die Fledermaus', Chacun à son goût:
https://www.youtube.com/watch?v=l6uEmtn56M0 )

-- 
Cheers,   "My opinions may have changed, 
Rick Moen but not the fact that I'm right."
r...@linuxmafia.com   -- Ashleigh Brilliant
McQ! (4x80)  
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[fsmithred]

On 07/25/2016 01:35 PM, Rick Moen wrote:
> Quoting Simon Hobson (li...@thehobsons.co.uk):
> 
>> Thanks, a bit heavy going for me at this time in the morning !
> 
> Well, if you want to learn the subject, there's an irreducible minimum
> of complexity, you know, but it was mostly a citation I gave as an
> accuracy cross-check on my ultra-quick extemporaneous description.
> I.e., you needn't take my word for this bit; here's a decent write-up.
> 
>> OK, that's what I thought, which is at odds with some comments that have 
>> been made.
> 
> Well, if you're referring to 'comments that have been made' about
> libsystemd0, the more useful (IMO) comments characterised what is
> actually present in that library, that it contains just interface code
> that absent systemd does[1] nothing -- and the way one knows that is to
> either read the source code or rely on the characterisations of those
> who have.  The fallback paranoia position then inevitably gets trotted
> out, of 'Yes, but evil nasty upstream in collusion with evil nasty
> distro packagers could _in the future_ add code that steals my lunch,
> sends my e-mails to the FSB, and opens a subspace channel to V'ger.'
> 
> The same is of course possible for the contents of every other Linux
> distribution package.  And the distro installers.  And maybe even the
> documentation, etc.
> 
> Far be it from me to recommend less paranoia, but I might make the
> modest and mild suggestion that unfocussed paranoia wastes time.
> 
> Upthread, I quite seriously suggested libsystemd0 package dependency
> should have long ago been FAQed, and, fellahs, you really ought to.
> This topic should have gotten put to rest years ago, rather than
> rehashed over and over.
> 
> [1] Someone disputed this characterisation by citing the GNOME gvfs 
> code in XFCE4 providing or not providing 'drive icons' depending on
> whether libsystemd0 is present or not.  The poster claimed this was
> libsystemd0 'doing something'.  To me, it looked like GNOME gvfs 'doing
> something', and further proof of GNOME being a fragile dependency
> hairball, as if that were needed.  But make up your own mind.
> 

Yeah, that was me, and it was based on partially incorrect testing. I set
the permissions to 000 on the wrong target. The test with the dummy
libsystemd0 package worked great to fulfill the package dependency and
allowed me to install gvfs, but gvfs wouldn't make the drive icons.

I repeated the permissions test on the correct target with the real
libsystemd (chmod 000 /lib/i386-linux-gnu/libsystemd.so.0.3.1)
and I got the same result. If libsystemd is not readable, gvfs won't show
the drive icons.

So yes, I agree with you that it looks like it's gvfs that's doing
something, and the something it's probably doing is using code in
libsystemd. Or maybe it's telling something else to do it. Either way, it
looks like libsystemd is passively providing code for something else to
use. If the code is being used by some program, that's doing something.

Is there another interpretation of these results?

-fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> Thanks, a bit heavy going for me at this time in the morning !

Well, if you want to learn the subject, there's an irreducible minimum
of complexity, you know, but it was mostly a citation I gave as an
accuracy cross-check on my ultra-quick extemporaneous description.
I.e., you needn't take my word for this bit; here's a decent write-up.

> OK, that's what I thought, which is at odds with some comments that have been 
> made.

Well, if you're referring to 'comments that have been made' about
libsystemd0, the more useful (IMO) comments characterised what is
actually present in that library, that it contains just interface code
that absent systemd does[1] nothing -- and the way one knows that is to
either read the source code or rely on the characterisations of those
who have.  The fallback paranoia position then inevitably gets trotted
out, of 'Yes, but evil nasty upstream in collusion with evil nasty
distro packagers could _in the future_ add code that steals my lunch,
sends my e-mails to the FSB, and opens a subspace channel to V'ger.'

The same is of course possible for the contents of every other Linux
distribution package.  And the distro installers.  And maybe even the
documentation, etc.

Far be it from me to recommend less paranoia, but I might make the
modest and mild suggestion that unfocussed paranoia wastes time.

Upthread, I quite seriously suggested libsystemd0 package dependency
should have long ago been FAQed, and, fellahs, you really ought to.
This topic should have gotten put to rest years ago, rather than
rehashed over and over.

[1] Someone disputed this characterisation by citing the GNOME gvfs 
code in XFCE4 providing or not providing 'drive icons' depending on
whether libsystemd0 is present or not.  The poster claimed this was
libsystemd0 'doing something'.  To me, it looked like GNOME gvfs 'doing
something', and further proof of GNOME being a fragile dependency
hairball, as if that were needed.  But make up your own mind.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Didier Kryn]

Le 25/07/2016 16:26, Simon Hobson a écrit :

I don't think even Poettering cold get away with deprecating the existing 
syslog call - force EVERY binary to change to not use syslog ?


I bet this is already done. I mean there's no need to use another 
API than syslog. There are already several alternative syslog servers 
all using the same API. Systemd can do the same; it is not complicated: 
just read the syslog socket. The problem is then for the admin to browse 
the f. binary logs.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

To expand a bit on what I wrote earlier - now it's finally condensed into 
something resembling a coherent thought.

Suppose, with SystemD running they decided to break normal syslog calls. Ie, 
they made it so that a program could not call syslog, but instead had to use a 
SystemD call. Given the way they are prepared to ride roughshod over anything 
that's in the way, it's not inconceivable that they'd try.
As a developer, you now have to sprinkle your code (or add a routine) to wrap 
every logging call with a "if systemd then ... else syslog" block. Devs might 
start moaning a bit about that, so then the next logical step is to add to 
libsystemd all the code needed to be able to log on non-systemd systems - so an 
application only needs to use the systemd logging call. It might start off as 
just a simple "if systemd then ... else syslog" routine, but then they can 
change it to just incorporate the logging from systemd altogether.
So now there's a bit of systemd, the much reviled logging system, that's now 
infiltrated the system.

OK, it's a bit made up, and I don't think even Poettering cold get away with 
deprecating the existing syslog call - force EVERY binary to change to not use 
syslog ? But it's an example of the process I could see them being happy to use 
to infiltrate their code onto systems, only "to be helpful" of course. I'm sure 
others could come up with more likely functions they might have a go at.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Hendrik Boom  wrote:

>> OK, so what makes libsystemd different from libc, which comes from the same
>> source? libc is stored in the same directory on the same debian servers...
> 
> It is a matter of trust, not of what is technically feasible.

Exactly

> Does one trust the libc developers more than the libsystemd developers?

That's not a hard question is it. One library comes from a team with a good 
track record, building a "tool to do specific things - not include the kitchen 
sink", and with respect for others' work. The other ... ermm ... the least said 
the better.
So is it paranoid to want to keep off your system a block of code written and 
maintained by "a bunch of vandals" ?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[info at smallinnovations.nl]

On 25-07-16 15:22, Hendrik Boom wrote:


It is a matter of trust, not of what is technically feasible.  Does one
trust the libc developers more than the libsystemd developers?

-- hendrik
___

That question is not very hard to answer.

Grtz.

Nick
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Didier Kryn]

Le 25/07/2016 15:17, Arnt Gulbrandsen a écrit :
OK, so what makes libsystemd different from libc, which comes from the 
same source? 


Not the same source: libc comes from GNU (and there are alternatives), 
while libsystemd comes from Lennart and the Red Hats.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Hendrik Boom]

On Mon, Jul 25, 2016 at 02:17:01PM +0100, Arnt Gulbrandsen wrote:
> Hendrik Boom writes:
> >Just linking isn't enough, unless there's something about the loading
> >process that I don't know.  (Maybe C++ has something special for module
> >initialization?)
> 
> No, nothing that special.
> 
> >But if an application is linked with libsystemd, it is likely to call one
> >of the libsystemd functions.  If so, putting a printf("Hello world!") into
> >that function would suffice.
> 
> OK, so what makes libsystemd different from libc, which comes from the same
> source? libc is stored in the same directory on the same debian servers...

It is a matter of trust, not of what is technically feasible.  Does one 
trust the libc developers more than the libsystemd developers?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Arnt Gulbrandsen]

Hendrik Boom writes:
Just linking isn't enough, unless there's something about the loading 
process that I don't know.  (Maybe C++ has something special for module 
initialization?)


No, nothing that special.

But if an application is linked with libsystemd, it is likely to call 
one of the libsystemd functions.  If so, putting a printf("Hello 
world!") into that function would suffice.


OK, so what makes libsystemd different from libc, which comes from the same 
source? libc is stored in the same directory on the same debian servers...


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Hendrik Boom]

On Mon, Jul 25, 2016 at 07:37:12AM +0100, Arnt Gulbrandsen wrote:
> Hi Rainer,
> 
> could you describe how this could be used to, say, make all applications
> that link with libsystemd print "Hello world!" in addition to their normal
> function?

Just linking isn't enough, unless there's something about the loading 
process that I don't know.  (Maybe C++ has something special for module 
initialization?)

But if an application is linked with libsystemd, it is likely to call 
one of the libsystemd functions.  If so, putting a printf("Hello 
world!") into that function would suffice.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

>> With a lib, is there any code or is it *JUST* a set of symbols ?

> This is a pretty good introduction to how libraries work and what they
> can contain:
> http://www.skyfree.org/linux/references/ELF_Format.pdf


Thanks, a bit heavy going for me at this time in the morning !

> Generically, a library can do just about anything, potentially.  A
> library is simply a set of compiled program routines that the get called
> by executables (call to function dlopen) that invoke particular
> functions within the libraries, and access symbols (call to function
> dlsym).  To know what's inside a _specific_ library, you need to look at
> that library's source code.

OK, that's what I thought, which is at odds with some comments that have been 
made.
So basically, if I have a subsystem "foobar" and a library "libfoobar0", and in 
that library I have a call called "init_foobar" then that call could do :
At one extreme, just recognise that foobar isn't installed and return a code to 
indicate that.
At the other extreme, do a whole load of stuff, even if foobar itself isn't 
installed - basically anything up to and including forking a persistent process 
?

Yes, the latter wouldn't make much sense, but it's possible ?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Arnt Gulbrandsen]

A library is code, data, fixups (I think that's the wrong word, sorry) and 
a little bit of red tape for the file format.


Fixups are changes to be made at runtime by the dynamic linker in order to 
make sure the code and calls work correctly at the runtime-assigned 
address(es). It may include loading subsidiary libraries. (The 
compiler/linker may optimise the library for a particular address, but the 
address-independency work is still done in principle.)


Data is static variables, values of constant strings and such.

Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> I think what he means, is that it allows devs/packagers to insert
> these calls and still have something that runs when systemd itself
> isn't installed. Not that the lib itself installs such calls.

First, thanks.  (I seriously wasn't trying to ignore anyone's
contributions, FWIW.  I merely saw a conversation that seemed
ill-omened, hence sought to gracefully exit it.)

Second, I'd be curious to see real-world specific examples of
whatever-this-is.

> With a lib, is there any code or is it *JUST* a set of symbols ?

Generically, a library can do just about anything, potentially.  A
library is simply a set of compiled program routines that the get called
by executables (call to function dlopen) that invoke particular
functions within the libraries, and access symbols (call to function
dlsym).  To know what's inside a _specific_ library, you need to look at
that library's source code.

This is a pretty good introduction to how libraries work and what they
can contain:
http://www.skyfree.org/linux/references/ELF_Format.pdf

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

> Quoting Rainer Weikusat (rweiku...@talktalk.net):
> 
>> To re-iterate this: 
> 
> [more very strangely worded, difficult-to-parse prose, seemingly alleging
> that library libsystemd0 can be used to insert 'calls' into unrelated
> applications -- which assertion in my view does not seem correct, if I
> am parsing this odd claim correctly]

I think what he means, is that it allows devs/packagers to insert these calls 
and still have something that runs when systemd itself isn't installed. Not 
that the lib itself installs such calls.

One thing I am not clear about ...
With a lib, is there any code or is it *JUST* a set of symbols ?
Ie, when a package makes one of these gratuitous calls (because systemd insists 
on doing stuff the hard way) to the library ... Is it what I'd consider a call 
(ie a jump into a routine executing real machine instructions) but that the 
code there is minimal and basically just returns "nah, systemd not installed 
mate" ? Or is there some sort of "magic" that makes the "call" returns 
something but there's no code in there ?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Arnt Gulbrandsen]

Hi Rainer,

could you describe how this could be used to, say, make all applications 
that link with libsystemd print "Hello world!" in addition to their normal 
function?


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Rainer Weikusat (rweiku...@talktalk.net):

> To re-iterate this: 

[more very strangely worded, difficult-to-parse prose, seemingly alleging
that library libsystemd0 can be used to insert 'calls' into unrelated
applications -- which assertion in my view does not seem correct, if I
am parsing this odd claim correctly]

> I honestly understand why stating this as it is causes hostile
> reactions.

I cannot recall having said anything hostile to you, but repeat that
perhaps some other, future discussion will go better -- and that I see
no point in continuing discussion.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rainer Weikusat]

Rick Moen  writes:
> Quoting Rainer Weikusat (rweiku...@talktalk.net):
>
>> I didn't expect you to stop the attempt to get a 'religious angle' into
>> this just because I pointed out that your interpretation was completely
>> wrong.
>
> I honestly don't understand the hostility, Rainier:

To re-iterate this: At the most basic level, a shared library enables
resolution of symbol references by the runtime linker with the ultimate
goal to get a program to run despite other files than the program file
itself are needed for this: Because of libsystemd, a systemd
sub-project, technically gratuitious calls to systemd-specific functions
can be inserted into unrelated applications.

I honestly understand why stating this as it is causes hostile
reactions.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Rainer Weikusat (rweiku...@talktalk.net):

> I didn't expect you to stop the attempt to get a 'religious angle' into
> this just because I pointed out that your interpretation was completely
> wrong.

I honestly don't understand the hostility, Rainier:   It seems like
anything I say you interpret as bad faith, where I was merely expressing
a preference for specifics and distrusting abstract discussion of
'purposes' in a discussion of software mechanics.  If I've erred, you
are certainly welcome to explain where.  And, if I failed to comprehend and
do justice to your thoughts, which is quite possible, I apologise:  I'm
entirely too fallible, and often caffeine-deficient.

Other that to stress those things, and express my regret for my own
failings and for this having not been a better sub-thread, I see no
point in continuing discussion.  Perhaps some other, future discussion
will go better.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> Here, AFAIU, systemd is different, it requires daemons to
> communicate with it using its own library, so that it forces itself
> into all the daemons.

I am reasonably confident that systemd in its role as an init can start
and stop services that have no dependency on its libraries.  (However, I
am not well informed on that subject however, because I've mostly
avoided systemd.)

> I'm sure we agree, just cheating on details :-)

D'accord.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rainer Weikusat]

Rick Moen  writes:
> Quoting Rainer Weikusat (rweiku...@talktalk.net):
>
>> That's neither 'abstract' nor 'teleological' as you yourself nicely
>> demonstrated by immediately coming up with an equivalent but different
>> term after reinterpreting my statement in a way it clearly wasn't meant
>> to be understood by exploiting ambiguities inherent in natural language.
>
> Seems pretty darned teleological and abstract to me.

I didn't expect you to stop the attempt to get a 'religious angle' into
this just because I pointed out that your interpretation was completely
wrong.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Didier Kryn]

Le 24/07/2016 23:55, Rick Moen a écrit :

The several init systems I've used such as SysVInit, OpenRC, and runit
do not require that 'applications' (services) talk to the init system using
glue libraries.  In fact, they don't need to talk to the init system at
all, unless I'm misremembering something.
Here, AFAIU, systemd is different, it requires daemons to 
communicate with it using its own library, so that it forces itself into 
all the daemons.




Somehow, I'm getting the feeling we're communicating at cross-purposes,
but I don't understand exactly how that happened.  Somehow we got from
libsystemd0 to... a discussion I don't entirely understand.


I'm sure we agree, just cheating on details :-)

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> Would it make any sense to have systemd with no application
> talking to it?

Someone (not me, but someone) might want it as an init system.  ;->

(Infamously, the thing aspires to be many more things, but somewhere
inside that mess there _is_ an init system:  This was the entire point of
V.R.'s / The Initfinder General's uselessd proof of concept.)

The several init systems I've used such as SysVInit, OpenRC, and runit
do not require that 'applications' (services) talk to the init system using
glue libraries.  In fact, they don't need to talk to the init system at
all, unless I'm misremembering something.

Somehow, I'm getting the feeling we're communicating at cross-purposes,
but I don't understand exactly how that happened.  Somehow we got from
libsystemd0 to... a discussion I don't entirely understand.

Anyhow, I concur with your upthread point that it would be good to know 
effective and reasonable ways to elminate unwanted library dependencies 
on a package-managed Linux system.  Rebuilding packages to reduce build
dependencies is one way, alternative packages with fewer library
dependencies is another -- and there may be other ways I'm not currently
recalling.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Didier Kryn]

Le 24/07/2016 23:29, Rick Moen a écrit :

Quoting Didier Kryn (k...@in2p3.fr):


Don't remember which package depends on some libkerberos5.
Assuming it's openssh or some component of pam.

Package openssh-client.

  $ ldd $(which ssh)
 linux-gate.so.1 =>  (0xb76ec000)
 libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7672000)
 libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 
(0xb751a000)
 libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7516000)
 libz.so.1 => /usr/lib/libz.so.1 (0xb7502000)
 libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb74d3000)
 libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb738c000)
 /lib/ld-linux.so.2 (0xb76ed000)
 libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb72da000)
 libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb72b7000)
 libcom_err.so.2 => /lib/libcom_err.so.2 (0xb72b4000)
 libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb72ad000)
 libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb72a9000)
 libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb729)
  $

On a system that actually uses Kerberos, pam_krb5.so also gets involved,
and I don't remember how that actually works.  (I've done some Kerberos
in setting up Hadoop on CentOS 6, but not much more than just getting it
going.)


This raises a fundamental problem of distros. openssh and pam must be
able to make use of as many authentication protocols as possible to
cover the needs of all users. How can you reach this goal without
linking them to the corresponding libraries?

It is indeed a thorny problem.  One common answer is the Gentoo-style
one where you employ USE flags or equivalent, and recompile & rebuild
packages to trim build dependencies.

It's certainly possible to carry out a similar action on a deb-packaged
distro by locally rebuilding deb packages, tweaking the 'rules' file
before compiling to reduce build dependencies.  Or, as you say, there
could be regular packages with several different flavours, some with
more dependencies, some with fewer.


The case of libsystemd0 is different. In an OS proposing
systemd, it is normal to have libsystemd0, but not in a system which
excludes it completely. Here is the choice Devuan faces: if systemd
is installable, then many packages must depend on libsystemd, if no
package depends on it, then systemd is not installable.

I followed you all the way to the last sentence, which I'm pretty
certain is simply not correct.

E.g., on my dest Debian 8 'Jessie' VM system (if I were to remove the
current embargoing of system from /etc/apt/preferences), I could remove
all packages that depend on libsystemd0, but then systemd would most
certainly be nonetheless installable.



Would it make any sense to have systemd with no application talking 
to it? Doesn't it imply it couldn't start any service. Therefore no DE, 
no ssh, no ntp, maybe even no login...


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Didier Kryn]

Le 18/07/2016 14:54, fsmithred a écrit :

With a dummy equivs libsystemd0, I get a trash icon that works, but the
removable drives don't show up on the desktop. When I remove the dummy
package and install the real libsystemd0, removables show up and
mount/eject work as expected.


I would consider a good thing to not have the crapy trash bin, but 
I definitely like to see the removable media and to be able to 
mount/umount them on mouse-click. gvfs is yet another Gnome stuff Xfce4 
depends on.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[fsmithred]

On 07/16/2016 05:12 AM, Rick Moen wrote:
> You probably wouldn't even like removing libsystemd0 entirely and
> replacing it with an 'equivs' recipe, which could also be done if one
> really, really, really were concerned.
> 
> But, for those interested in that technique, see:  'How To Satisfy
> Debian Dependencies Without Installing The Stupid Package' on
> http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html


Pretty cool trick. I tried it and got mixed results. I'm running without
libsystemd0 here, so I can't have gvfs-daemons. That means there's no
trash icon on the desktop and removable drives don't show up on the
desktop when they're plugged it.

With a dummy equivs libsystemd0, I get a trash icon that works, but the
removable drives don't show up on the desktop. When I remove the dummy
package and install the real libsystemd0, removables show up and
mount/eject work as expected.

I don't have time right now to complete the test, but I'd like to try Adam
Borowski's repackaged gvfs. I'm guessing it will work.

-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Dragan FOSS (dragan.f...@gmx.com):

> >The purpose of libsystemd0 is to enable packages whose code has been
> >'enhanced' with spurious systemd depedencies to work on systemd-less
> >systems. That's absolutely not harmless.
> 
> So, why not remove it? ;>
> TRIOS == excellence in simplicity :)

Very nice!  Thanks for offering that.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Rainer Weikusat (rweiku...@talktalk.net):

> The purpose of libsystemd0 is to enable packages whose code has been
> 'enhanced' with spurious systemd depedencies to work on systemd-less
> systems. That's absolutely not harmless.

Your implied concept of 'purpose' is IMO a bit problematically abstract
and teleological for my taste.  What I find more connected to the real
world, clearer in reference to my experience, is the concept of
_function_, i.e., what things do.

As has been abundantly documented, without systemd itself present, 
/lib/[$ARCH]/libsystemd.so.0 does basically nothing at all, as it cannot
do anything.  (I'd rather have it gone, and have suggested some ways to
do so, which should be tested before use on production systems.)

If you insist on talking, by contrast, about 'purpose', I'd say that the
purpose of every piece of software on my server is to support my and my
users' computing.  The codebases are of course severely imperfect at
that, because code is imperfect.  If you disagree and think they have
different purposes, I'll just stoutly assert that it's because you hew
to a different religion, while I profess Me-ism.  ;->

Be careful where attribution of 'purpose' to code takes you:

[rick@linuxmafia]
~ $ ldd $(which ssh)
linux-gate.so.1 =>  (0xb77b)
libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7736000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb75de000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb75da000)
libz.so.1 => /usr/lib/libz.so.1 (0xb75c6000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7597000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb745)
/lib/ld-linux.so.2 (0xb77b1000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb739e000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb737b000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7378000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7371000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb736d000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7354000)
[rick@linuxmafia]
~ $ 

Is the 'purpose' of /usr/bin/ssh being dependent on sonames
libgssapi_krb5.so.2 and libkrb5.so.3 on my Kerberos-less server to
enable packages whose code has been 'enhanced' with spurious Kerberos
dependencies to work on Kerberos-less systems?  Is the 'purpose' of 
/usr/bin/ssh being dependent on soname the enabling of packages whose
code has been 'enhanced' with spurious kernel keyutils key-retention
functions to work on keyutils-less systems?

It's all bit high-flown for me, and a bit too much like theology.
Personally, I would rather just be concerned with what things _do_.

And, of course, with process:  In my experience, packagers often build
into dynamic binaries calls to libraries that somebody, somewhere
_might_ use.  E.g., I doubt that the packager of /usr/bin/ssh is a
secret agent attempting to sneak Kerberos into everyone's computing.

But you knew all that, right?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Dragan FOSS]

The purpose of libsystemd0 is to enable packages whose code has been
'enhanced' with spurious systemd depedencies to work on systemd-less
systems. That's absolutely not harmless.


So, why not remove it? ;>
TRIOS == excellence in simplicity :)

***
[dragan@trios-eudev][~/Desktop]$ cat /etc/apt/sources.list
deb http://http.debian.net/debian/ jessie non-free contrib main
deb-src http://http.debian.net/debian/ jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
deb http://http.debian.net/debian/ jessie-updates main contrib non-free
deb-src http://http.debian.net/debian/ jessie-updates main contrib non-free
deb http://http.debian.net/debian/ jessie-backports non-free contrib main
deb-src http://http.debian.net/debian/ jessie-backports main contrib 
non-free

[dragan@trios-eudev][~/Desktop]$ cat /etc/apt/sources.list.d/trios.list
deb http://mirror.org.rs/trios/mia/ mia main sysdfree zfs eudev
deb-src http://mirror.org.rs/trios/mia/ mia main sysdfree zfs eudev

[dragan@trios-eudev][~/Desktop]$ cat /etc/apt/preferences.d/trios.pref
Package: *
Pin: origin "mirror.org.rs"
Pin-Priority: 1001

Package: systemd
Pin: release *
Pin-Priority: -1

Package: systemd-shim
Pin: release *
Pin-Priority: -1

Package: systemd-sysv
Pin: release *
Pin-Priority: -1

Package: libsystemd0
Pin: release *
Pin-Priority: -1

Package: libsystemd0:i386
Pin: release *
Pin-Priority: -1

Package: libsystemd-dev
Pin: release *
Pin-Priority: -1

Package: packagekit
Pin: release *
Pin-Priority: -1


[dragan@trios-eudev][~/Desktop]$ apt-cache policy libsystemd0
libsystemd0:
  Installed: (none)
  Candidate: (none)
  Package pin: 215-17+deb8u4
  Version table:
 215-17+deb8u4 -1
500 http://http.debian.net/debian/ jessie/main amd64 Packages
[dragan@trios-eudev][~/Desktop]$

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rainer Weikusat]

Rick Moen  writes:

[...]

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

The purpose of libsystemd0 is to enable packages whose code has been
'enhanced' with spurious systemd depedencies to work on systemd-less
systems. That's absolutely not harmless.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[aitor_czr]

LOL,

On 07/17/2016 02:00 PM, Rick Moen  wrote:

On 07/16/2016 10:15 PM, Rick Moen  wrote:

> >Iron-clad proof that Bill Gates owns Fort Knox.  ;->

>
>Linuxmafia ??

I did get a very bemused mail from the main organiser of Linux Silicia,
because of the domain name.  (It does have the advantage of being
somewhat memorable.)


I've been in Milano, Veronia, Pisa, Venecia, Rome, Firence, Napoles, 
Salerno, The Lago of Como...


My photo in twitter is taken in Como :)

LOL again :)

  Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> That's the point - I never suggested it didn't. But it doesn't work
> for me - as in that's not a route I'm happy taking in order to deal
> with it.

I wouldn't dream of arguing against people's likes.

> Thank you for that link, I was aware of the equivs feature, but it's
> not something I've used.  But, for testing it can be simulated by just
> over-riding dependencies, as in dpkg --force-depends -r libsystemd0
> And hey presto, the package causing me problems would fail to start -
> needless to say, when it calls a function in that library the call
> fails.

That indeed removes it, but the point is that an equivs entry tells the
package system it's installed, even if it isn't.

You were saying it's not good enough for libsytemd0 to be present at
all, not even with a cron job ensuring it has 000 permissions every
night, and possibly not even with the binary file set immutable using
'chattr +i':  Well, using an equivs entry, instead, should suffice to
satisfy that objection.  In that case, you can removed the lib entirely 
(using force options as you suggest), and the equivs entry makes apt lie
to itself with the aim of ensuring that the lib never gets reinstalled.

> > Duct tape is cool.
> 
> Over here, the common term is gaffer tape.

I last lived in Blighty during Ted Heath's administration (Trinity
Church Square, Southwark), so I'm rather outmoded, but my understanding
was that backing and adhesive differs between the two types.

https://forums.overclockers.co.uk/showthread.php?t=18499183

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Steve Litt]

On Sat, 16 Jul 2016 13:15:23 -0700
Rick Moen  wrote:

> Quoting Hendrik Boom (hend...@topoi.pooq.com):
> 
> > Whether he uses Devuan in a virtual machine is not directly relevant
> > to me.  I appreciate that when he's tinkering with the innards of a
> > distro it may be vastly convenient to do it in a virtual machine
> > rather than bare metal, expecially if things go wrong.  
> 
> I talk to Steve in other contexts, and he is overwhelmingly a Void
> Linux user.  He doesn't really use Devuan in any significant sense at
> all. Thus my point.  But it's just an observation in passing -- that
> the impassioned rhetoric was particularly funny in that light.

What Rick says is true. For my use case, Void is better than Devuan.

But I have a wife, a son, and two daughters, and my life is much easier
with them running Devuan.

And there's something else. The Devuan project has soul. Just look at
the interactions, the accomplishments. It's like being a soul singer in
Detroit in the 1964, like being an outdoor roller skater in Venice,
CA in 1979, or starting up a website in 1995: Right place, right time,
the best people.

If, by hanging out here, I can in some little ways help the cause,
that makes me very happy.
 
SteveT

Steve Litt 
July 2016 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Sorry about typo.

> I did get a very bemused mail from the main organiser of Linux Silicia, 
> because of the domain name.^^^

Sicilia, even.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting aitor_czr (aitor_...@gnuinos.org):

> On 07/16/2016 10:15 PM, Rick Moen  wrote:
> >Iron-clad proof that Bill Gates owns Fort Knox.  ;->
> 
> Linuxmafia ??

I did get a very bemused mail from the main organiser of Linux Silicia, 
because of the domain name.  (It does have the advantage of being
somewhat memorable.)

-- 
Cheers,My pid is Inigo Montoya.  You kill -9
Rick Moen  my parent process.  Prepare to vi.
r...@linuxmafia.com
McQ!  (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[aitor_czr]

On 07/16/2016 10:15 PM, Rick Moen  wrote:

Iron-clad proof that Bill Gates owns Fort Knox.  ;->


Linuxmafia ??

  Aitor,
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Hendrik Boom  wrote:

> That said, I find it immensely convenient that someone else is 
> providing me with a systemd-free distro that's a natural 
> continuation of the Debian I've been using for years.

+1

> What's left is a matter of taste.
> There's no point arguig about taste.

And +1 again. It does seem to have come down to that - plus a little 
misinterpretation of what's been written.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> Whether he uses Devuan in a virtual machine is not directly relevant
> to me.  I appreciate that when he's tinkering with the innards of a
> distro it may be vastly convenient to do it in a virtual machine
> rather than bare metal, expecially if things go wrong.

I talk to Steve in other contexts, and he is overwhelmingly a Void Linux
user.  He doesn't really use Devuan in any significant sense at all.
Thus my point.  But it's just an observation in passing -- that the
impassioned rhetoric was particularly funny in that light.


> That said, I find it immensely convenient that someone else is 
> providing me with a systemd-free distro that's a natural 
> continuation of the Debian I've been using for years.  


> It's a lot easier not to have to do the pinning and monitoring myself.

In case the point was somehow missed despite repeating it a number of
times, 'do it yourself' is limited.  What would scale better is
something similar to what the Siduction and Aptosid Debian-variant
communities do (in their cases, imposing a policy on Sid =
Debian-unstable).

I can thus use Siduction's or Aptosid's policy-applied fixes to Sid 
without 'doing the pinning and monitoring myself', if I wish to have a
stablised desktop variant of Debian-unstable.

A user of Siduction or Aptosid might say 'I find it immensely convenient
that someone else os providing me with a stablised cutting-edge Debian
desktop system that's a natural continuation of the Debian Sid I've been
using for years.'

And that would be not a fork, you understand.  And that would be 'for
people like you, who like something that just works, and is infinitely
configurable'.

Nothing wrong with forks, of course.


> I do wish you two would stop arguing.  You seem to agree on all 
> substantive issues; 

Except Steve is all upset over my attacking Devuan Project, which I did
not do.  (Which set all of this waste of time off.)  And he keeps
posting logical fallacies asserting various things including the alleged
necessity of distro forking because he likes Devuan, which of course
doesn't follow at all.

I have nothing I need to add, though.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Hendrik Boom]

On Sat, Jul 16, 2016 at 12:44:33PM -0700, Rick Moen wrote:
> Quoting Steve Litt (sl...@troubleshooters.com):
> 
> > Due to my needs, my situation, my beliefs, and my skillset, an OS from
> > the Debian project doesn't work for me. I've said why about 15 times on
> > two mailing lists. For *me*,  what works is the Devuan fork. So for me,
> > the situation merited a fork.
> 
> I'm glad Devuan works for you (although it would be more truthful for
> you to disclose here that you don't _actually_ run it; you use Void
> Linux and have an instance of Devuan in a VM that you normally do
> not use).

Whether he uses Devuan in a virtual machine is not directly relevant to me.
I appreciate that when he's tinkering with the innards of a distro it may be 
vastly convenient to do it in a virtual machine rather than bare metal, 
expecially if things go wrong.

That said, I find it immensely convenient that someone else is 
providing me with a systemd-free distro that's a natural 
continuation of the Debian I've been using for years.  It's a 
lot easier not to have to do the pinning and monitoring myself.
I dumped KDE and gnome when they turned weird a while ago.  I 
use icewm and xfce as window managers.  I have no need for 
systemd, and would prefer it stay off my machine.

You can pin all you want on your machine.  You can replace 
whatever you want on your Debian system.  But Devuan is 
for people like me, who like something that just works, and is 
infinitely configurable.

I do wish you two would stop arguing.  You seem to agree on all 
substantive issues; you even agree that forking and pinning are 
both methods of avoiding systemd.  What's left is a matter of taste.
There's no point arguig about taste.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> Due to my needs, my situation, my beliefs, and my skillset, an OS from
> the Debian project doesn't work for me. I've said why about 15 times on
> two mailing lists. For *me*,  what works is the Devuan fork. So for me,
> the situation merited a fork.

I'm glad Devuan works for you (although it would be more truthful for
you to disclose here that you don't _actually_ run it; you use Void
Linux and have an instance of Devuan in a VM that you normally do
not use).

You appear to still creating confusion by using the word 'merited' in
a way that has a logic problem.  (The logic error in question is called
'affirming the consequent'.)

You like Devuan (as do I) and therefore appreciate that it exists (find it
'merited' in the sense that you like it existing).  You claim that this
justifies the action of a distribution fork, because there would have
been no other way for the Devuan Project to exist.  But that is assuming
the result you are purporting to arrive at.

https://en.wikipedia.org/wiki/Affirming_the_consequent

  If Bill Gates owns Fort Knox, then he is rich.
  Bill Gates is rich.
  Therefore, Bill Gates owns Fort Knox.

  Owning Fort Knox is not the only way to be rich.  Any number of other
  ways exist to be rich.

Other ways exist besides forking distribution X to perpetuate
distroX-variant communities.  The mere fact that you like the result of
that fork doesn't mean other means of achieving that goal might not have
been equally effective and a lot easier.  And Bill Gates might have
gotten rich through stock ownership rather than owning Federal gold
repositories.

You keep wanting to work out that I had 'attacked' the Devuan Project or
claimed it wasn't right for you.  I have never done either -- though I'd
be a lot more impressed with your fervent devotion to the Devuan Project
if you were not, in fact, running Void Linux.



> > If you're worried about the... um... ongoing threat of the... um...
> > non-function of a library between cron runs, you could set chattr +i 
> > in addition.
> 
> If my interpretation of your preceding paragraph is right, the tone of
> your preceding paragraph indicates skepticism on your part that the
> Debian project will keep changing things such that to keep my box
> systemd free I keep having to change my packagemanager-foo.

No, that is not what that paragraph said.

That paragraph was merely boggling over the notion of libsystemd0 being
a threat or any competent Linux admin being unable to deal with it.

But have fun with the apocalyptic thinking.

 
> Your preceding paragraph, and the one it responds to, precisely make my
> point. In the absence of guarantees, each of us picks what he thinks
> most likely to succeed. Naturally, different people pick different
> things. That doesn't make anybody wrong.

But people _do_ find countless other ways to err.  ;->

I'll bet you didn't notice that you didn't actually say anything.


> First, your packagemanager-foo is cool. I didn't think it possible.

Frankly, *I'm* not even very good at it.  I just collect clues from
others -- and there's absolutely nothing I've mentioned any of these
places that isn't fully covered in the basic distro documentation.

> It's a real boon for people hating systemd but not willing to switch
> away from Debian, as well as people who agree with you that it will
> always be possible to extricate systemd from Debian with the proper
> package manager maneuvers. 

That is not exactly what I said.

Occasional third-party (or local) packages may also be necessary --
perhaps from Devuan Project.  _Or_ other problems might come down the
pike that I haven't anticipated, necessitating other measures.  And, as
I said, I've switched distributions four times (to the best of my
recollection) since first trying Linux in 1993, and it's reasonable to
assume that I will again.


> Second, I don't pick a distro exclusively for technological reasons,
> and Devuan wasn't created exclusively for technological reasons. Read
> https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html ,
> which to me is Devuan's Declaration of Independence. Read the paragraph
> starting with "The problem is obviously not just technical" and the
> paragraph after it.

Yes, I read that at the time.  I think there are some key (and very
telling) judgement errors in there, notably confusing bureaucratic
mishap with conspiracy (e.g., 'take-over of Debian by the GNOME project
agenda').  Neither the Debian Project nor the GNOME Project is anywhere
near that organised, and the truth as usual involves a great deal more
hapless blundering and a great deal less sinister plotting.

> For me, with my use case, the situation merited a fork and nothing less.

Iron-clad proof that Bill Gates owns Fort Knox.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Steve Litt]

On Sat, 16 Jul 2016 02:12:01 -0700
Rick Moen  wrote:

> Quoting Simon Hobson (li...@thehobsons.co.uk):
> 
> > Rick Moen  wrote:
> >   
> > > 'Doing' something that is functionally indistinguishable from
> > > doing nothing.  And a '000' rights mask would be fully effective
> > > paranoia insurance.  
> > 
> > Present tense and gaffer tape. Of course, any libsystemd package
> > update will rip that gaffer tape off so it's one more thing to keep
> > checking/fixing on an ongoing basis.  
> 
> Well, Works for Me.{tm}

That's precisely the point. Due to your needs, your situation, your
beliefs, and your skillset, de-systemd'ed Debian works for you. Nobody
said you shouldn't use it. Nobody said you should use Devuan or
contribute to Devuan. Debian with the magic sauce packagemanager-foo
works for you, end of story.

Due to my needs, my situation, my beliefs, and my skillset, an OS from
the Debian project doesn't work for me. I've said why about 15 times on
two mailing lists. For *me*,  what works is the Devuan fork. So for me,
the situation merited a fork.

> 
> I've only been a senior system administrator for a few decades, so
> it's possible that you know this subject a lot better.
> 
> If you're worried about the... um... ongoing threat of the... um...
> non-function of a library between cron runs, you could set chattr +i 
> in addition.

If my interpretation of your preceding paragraph is right, the tone of
your preceding paragraph indicates skepticism on your part that the
Debian project will keep changing things such that to keep my box
systemd free I keep having to change my packagemanager-foo. This is the
difference between you an me: I believe such changes to be the more
likely scenario. We'll both know for sure in two or three years, and
no, I'm not going to make a monetary bet.

But even if you were totally right and I were whack-job paranoid, that
doesn't make Devuan any less right for me. There are many use cases in
this world, and in some of them, Devuan fits the bill much better than
packagemanager-foo'ed Debian.

[snip]

> 
> > Can you, with crystal ball, 100% guarantee that something like
> > libsystemd won't get "feature enhanced" at some point ?  
> 
> Can you, with crystal ball, 100% guarantee that I won't deal with my
> system to effectively apply local policy using regular open source
> practices?  I've done it for only a couple of decades on Linux, so
> it's probably just a total fluke that I've gotten away with it so far.

Your preceding paragraph, and the one it responds to, precisely make my
point. In the absence of guarantees, each of us picks what he thinks
most likely to succeed. Naturally, different people pick different
things. That doesn't make anybody wrong.

[snip]
 
> You seem to be big on high-drama, apocalyptic predictions.  

OK, so am I. So are a lot of people. So I (and they) choose Devuan.

Two more things...

First, your packagemanager-foo is cool. I didn't think it possible.
It's a real boon for people hating systemd but not willing to switch
away from Debian, as well as people who agree with you that it will
always be possible to extricate systemd from Debian with the proper
package manager maneuvers. The more escapes from systemd, the better.

Second, I don't pick a distro exclusively for technological reasons,
and Devuan wasn't created exclusively for technological reasons. Read
https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html ,
which to me is Devuan's Declaration of Independence. Read the paragraph
starting with "The problem is obviously not just technical" and the
paragraph after it.

For me, with my use case, the situation merited a fork and nothing less.
 
SteveT

Steve Litt 
July 2016 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Peter Olson]

> On July 16, 2016 at 8:51 AM Simon Hobson  wrote:

  [...]

> > Duct tape, actually.  It's like the Force.  It has a light side and a
> > dark side, and it holds the universe together.
> > 
> > Duct tape is cool.
> 
> Over here, the common term is gaffer tape. Duct tape is a common term as 
> well, and of course the commercial product playing on the homophone (if I go 
> the right word) with Duck Tape

Gaffer tape and {duct|duck} tape are different products.  Gaffer tape is less 
adhesive and is designed to be removed easily.  It is more expensive :-)  If 
you have ever used the other tape to secure cables to the floor and then 
uprooted those cables when tearing down, you will know the misery of trying to 
remove the other kind of tape now wrapped seamlessly around the cable.

Peter Olson
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

I think we're arguing in violent agreement - there is more than one way to 
approach the issue, more than one attitude to "risk", and what works for one 
person isn't necessarily what works for someone else. Isn't that a key tenet of 
the FOSS way - the freedom of choice ?


> Well, Works for Me.{™}

That's the point - I never suggested it didn't. But it doesn't work for me - as 
in that's not a route I'm happy taking in order to deal with it.

> Can you, with crystal ball, 100% guarantee that I won't deal with my
> system to effectively apply local policy using regular open source
> practices?

And again, you seem to be reading into it things I haven't said. I'm sure 
you'll carry on adding more tape as required and achieve the result you want in 
a way you are happy with. As I said, that's not a route I'm happy taking. I may 
have to if the combination of factors (including my own skill set) conspire to 
make it the least bad way to achieve something, but until then I'll be avoiding 
it. That doesn't mean I have a problem with you doing that - as you say, it 
works for you.



> You probably wouldn't even like removing libsystemd0 entirely and
> replacing it with an 'equivs' recipe, which could also be done if one
> really, really, really were concerned.
> 
> But, for those interested in that technique, see:  'How To Satisfy
> Debian Dependencies Without Installing The Stupid Package' on
> http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html
> 
> (You're welcome!)

Thank you for that link, I was aware of the equivs feature, but it's not 
something I've used.
But, for testing it can be simulated by just over-riding dependencies, as in 
dpkg --force-depends -r libsystemd0
And hey presto, the package causing me problems would fail to start - needless 
to say, when it calls a function in that library the call fails.

Now, if the devs/maintainers used a "if it's there call it, if it isn't then 
don't" approach then I could see that working. I assume that is a possible way 
of calling library functions given the number of programs with optional 
dependencies/features. When I raised it with the particular package 
maintainers, someone off-list sent me an email saying (of the response I got) 
"if that's the support department, I'd hate to see the complaints department" !


> Duct tape, actually.  It's like the Force.  It has a light side and a
> dark side, and it holds the universe together.
> 
> Duct tape is cool.

Over here, the common term is gaffer tape. Duct tape is a common term as well, 
and of course the commercial product playing on the homophone (if I go the 
right word) with Duck Tape

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Walter (si...@gikaku.com):

> I want to give a little bit of constructive criticism.
> 
> "A fool is known by a multitude of words." That is not to say you
> are fool. I don't know you. However, everyone is pretty busy. So if
> you want to express something accurately, minimize verbiage and
> refrain from using argumentum ad hominem. I read some of your
> conversation with Steve on SVLUG. Because it was so long, I didn't
> read everything. However, from what I did read, to me it you sounded
> like you had an axe to grind.
>
> That might not the case.

I thank you for your possibly-well-intentioned if highly selective and
somewhat passive-aggressive unsolicited personal advice.

> It seems that you are asking: "What is the reason for Devuan when
> the same thing can be accomplished in a simpler way?" 

No.  I am _not_ asking what is the reason for Devuan.

Devuan didn't, and doesn't, need to give a reason, and I didn't ask for
one.  I'm sure Jaromil and the other founders are competent planners,
and they have every right to do what they wish.  And I am glad the
project exists, and happy to have its products available.

I merely stated my opinion that the same thing could also have been
accomplished through less-drastic means.  That view might be correct, or
it might be incorrect.  I merely expressed the opinion.  Elsewhere.


> It seems to me Debian leaders want Debian to be the new shinny.

Really?  That would be pretty delusional, on their part, because it's
pretty much never going to be, and never has been.


> By talking so much about this and that and wasting people's time, I
> winder if you have an agenda to push.

I 'winder' if you have been attentively reading, in part because:


> So here is a disclaimer for you:

Um, why for _me_? 

I deliberately implement a no-systemd-thanks policy on my machines, by
preference.  Was that, incredibly, somehow not clear?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> Rick Moen  wrote:
> 
> > 'Doing' something that is functionally indistinguishable from doing
> > nothing.  And a '000' rights mask would be fully effective paranoia
> > insurance.
> 
> Present tense and gaffer tape. Of course, any libsystemd package
> update will rip that gaffer tape off so it's one more thing to keep
> checking/fixing on an ongoing basis.

Well, Works for Me.{tm}

I've only been a senior system administrator for a few decades, so it's
possible that you know this subject a lot better.

If you're worried about the... um... ongoing threat of the... um...
non-function of a library between cron runs, you could set chattr +i 
in addition.

But I'm reasonably sure you won't like that, either.

You probably wouldn't even like removing libsystemd0 entirely and
replacing it with an 'equivs' recipe, which could also be done if one
really, really, really were concerned.

But, for those interested in that technique, see:  'How To Satisfy
Debian Dependencies Without Installing The Stupid Package' on
http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html

(You're welcome!)


> > Are you capable of preventing the installation of package systemd?
> I am.  Thus, libsystemd0 does, in end-result, nothing.
> 
> Present tense again.

Present tense and practice of system administration.  It's totally my
fault for imagining that I've gotten some experience running systems and
learned some useful tricks.  Probably a misperception on my part.

> Can you, with crystal ball, 100% guarantee that something like
> libsystemd won't get "feature enhanced" at some point ?

Can you, with crystal ball, 100% guarantee that I won't deal with my
system to effectively apply local policy using regular open source
practices?  I've done it for only a couple of decades on Linux, so it's
probably just a total fluke that I've gotten away with it so far.

 
> I understand that you don't see much point to Devuan because clearly
> for you, gaffer tape works fine.

Duct tape, actually.  It's like the Force.  It has a light side and a
dark side, and it holds the universe together.

Duct tape is cool.

You seem to be big on high-drama, apocalyptic predictions.  And indeed
the sky may indeed be soon to fall, the stars in their alignment, and
dread Cthulhu and the Deep Ones stirring in R'lyeh.  Metaphorically, at
least.  (Sorry, I've been reading Charlie Stross's latest Laundry Files
book.)

I've switched Linux distributions several times before, for good and
compelling reasons at the time.  It'll probably end up doing it again.
But I'll bet it won't be over libsystemd0.  Because, really.

> And one more thing.  You've argued about (or at least discussed) the %
> of packages dependent on systemd. When you came up with your
> 90-something percent, was that direct dependencies, or did you account
> for A depends on B, B depends on C, C depends on D, and D depends on
> systemd ? 

The latter, of course.  And this is documented on my Web page, by the
way.

I might have missed some dependency chains, because it was a great deal of
information to collate and HTMLise -- but I listed all of the ones I
found through iterative runs using apt-cache.  Please kindly advise of
any I missed, and I will be delighted to correct the omission, and credit
you for the help.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless

[Simon Hobson]

Rick Moen  wrote:

> 'Doing' something that is functionally indistinguishable from doing
> nothing.  And a '000' rights mask would be fully effective paranoia
> insurance.

Present tense and gaffer tape. Of course, any libsystemd package update will 
rip that gaffer tape off so it's one more thing to keep checking/fixing on an 
ongoing basis.

> Are you capable of preventing the installation of package systemd?  I
> am.  Thus, libsystemd0 does, in end-result, nothing.

Present tense again.

Can you, with crystal ball, 100% guarantee that something like libsystemd won't 
get "feature enhanced" at some point ? When packages have gone down the route 
of gratuitous dependencies and then start finding that it would be easier if 
libsystemd did "just this one thing" even when systemd itself isn't installed.
I would not put such actions past the systemd gang "just to make life easier" 
for those packagers "supporting" them but with users fiddling with pinning and 
such.

I understand that you don't see much point to Devuan because clearly for you, 
gaffer tape works fine. I see a point because pinning etc is only gaffer tape, 
and as time goes one you'll need more and more gaffer tape. Don't get me wrong, 
gaffer tape is great stuff - but I'd be mighty peed off if I took my car in for 
(eg) a service and it came back with bits held on with gaffer tape.


And one more thing.
You've argued about (or at least discussed) the % of packages dependent on 
systemd. When you came up with your 90-something percent, was that direct 
dependencies, or did you account for A depends on B, B depends on C, C depends 
on D, and D depends on systemd ? Because if you didn't, then you'll have 
included A, B, and C in your count which is bogus.
But the actual number is irrelevant anyway. I really really REALLY don't give a 
fig if there are 40+k packages that don't depend on systemd if there is ONE 
package I need to run which does. We need 100% - not 99%, not 99.9%, but 100% - 
of the packages I want/need to run to be free of systemd in order to be systemd 
free.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng