Marco d'Itri writes ("Re: Is missing SysV-init support a bug?"):
> On Dec 31, Simon Richter <s...@debian.org> wrote:
> > These are running stretch, and I would like to upgrade them without
> > breaking my existing scripts, which assume sysvinit with runlevels
&g
Josh Triplett writes:
> It seems far harder to do so for a service that provides no
> daemonization support at all, expects socket or D-Bus activation,
> integrates with containerization, or otherwise makes use of the
> variety of mechanisms that make it far easier to
]] Simon Richter
> A daemon must be capable of running standalone and dealing with the
> fallout of depended-on services shutting down, restarting, crashing or
> being generally unavailable. All of these are significantly harder to
> get right than startup in a SysV environment.
A lot of the
Hi,
On 01.01.2018 17:42, Josh Triplett wrote:
> There's a difference between "dropping support" and "not mandating
> support".
Ideally, yes, but in practice the difference isn't very large. The main
reasons I see for people to use sysvinit are:
- reliability: there have been a few interesting
Josh Triplett writes:
> This thread started with the question of "is it a bug to not have
> sysvinit support". And I think the answer, at this point, is "yes, but
> depending on the level of additional code and maintenance required, it
> might potentially be a wishlist
On Mon, Jan 01, 2018 at 08:42:52AM -0800, Josh Triplett wrote:
It seems easy
enough to just write a "missing" init script, or accept a patch for one.
It seems far harder to do so for a service that provides no
daemonization support at all, expects socket or D-Bus activation,
integrates with
Russ Allbery wrote:
> Josh Triplett writes:
> > Russ Allbery wrote:
>
>>> It does, however, mean that it's a good idea for us to continue to
>>> support sysvinit.
>
>> Not quite. It means we should maintain support for sysvinit *scripts*
>> for the foreseeable future;
Josh Triplett writes:
> Russ Allbery wrote:
>> It does, however, mean that it's a good idea for us to continue to
>> support sysvinit.
> Not quite. It means we should maintain support for sysvinit *scripts*
> for the foreseeable future; there's no good reason for us to
Russ Allbery wrote:
> m...@linux.it (Marco d'Itri) writes:
> > On Dec 31, Simon Richter wrote:
>
> >> These are running stretch, and I would like to upgrade them without
> >> breaking my existing scripts, which assume sysvinit with runlevels
> >> (including one-shot runlevels).
On 12/31/2017 07:19 PM, Michael Biebl wrote:
> Am 30.12.2017 um 14:27 schrieb Alex Mestiashvili:
>> On 12/30/2017 01:46 PM, Michael Biebl wrote:
>>> Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
>>>
There are some cases when using sysvinit is preferred over systemd.
AFAIK there is no
Am 30.12.2017 um 14:27 schrieb Alex Mestiashvili:
> On 12/30/2017 01:46 PM, Michael Biebl wrote:
>> Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
>>
>>> There are some cases when using sysvinit is preferred over systemd.
>>> AFAIK there is no way drop some capabilities with systemd geared
m...@linux.it (Marco d'Itri) writes:
> On Dec 31, Simon Richter wrote:
>> These are running stretch, and I would like to upgrade them without
>> breaking my existing scripts, which assume sysvinit with runlevels
>> (including one-shot runlevels).
> Somebody having legacy
On Dec 31, Simon Richter wrote:
> > There are some cases when using sysvinit is preferred over systemd.
[...]
> These are running stretch, and I would like to upgrade them without
> breaking my existing scripts, which assume sysvinit with runlevels
> (including one-shot
W. Martin Borgert wrote...
> I'm not sure, whether missing SysV support is wishlist, minor,
> or normal. I would accept normal, but some maintainers would
> downgrade severity.
In my understanding of "universal" (Debian, operating system, y'know)
the goal should be to run on as many platforms as
Hi,
On 30.12.2017 13:02, Alex Mestiashvili wrote:
>> I would guess that the vast majority of folks still using sysvinit with
>> Debian are running wheezy or older, and thus removing sysvinit scripts
>> from packages in unstable wouldn't affect them. But maybe that still
>> leaves a reasonable
On Sun, Dec 31, 2017 at 12:54 PM, Steve Langasek wrote:
> And in what context would you find yourself trying to run a Debian init
> system in such an environment?
Often mainline Linux doesn't support particular embedded/mobile
systems (especially ARM/MIPS) or has a bug that isn't present in the
On Sat, Dec 30, 2017 at 01:38:10PM +0100, W. Martin Borgert wrote:
> On 2017-12-30 13:02, Alex Mestiashvili wrote:
> > There are some cases when using sysvinit is preferred over systemd.
> > AFAIK there is no way drop some capabilities with systemd geared linux
> > containers while it is possible
On Dec 30, Alex Mestiashvili wrote:
> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.
Here it is: no CAP_SYS_ADMIN.
# cat /etc/systemd/nspawn/secure.nspawn
[Exec]
DropCapability=CAP_AUDIT_CONTROL
On 12/30/2017 01:46 PM, Michael Biebl wrote:
> Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
>
>> There are some cases when using sysvinit is preferred over systemd.
>> AFAIK there is no way drop some capabilities with systemd geared linux
>> containers while it is possible with sysvinit.
>
Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
> There are some cases when using sysvinit is preferred over systemd.
> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.
It's the first time I hear about this. Can you please
On 2017-12-30 13:02, Alex Mestiashvili wrote:
> There are some cases when using sysvinit is preferred over systemd.
> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.
Unfortunately, on some embedded and/or mobile systems, one
On 08/26/2016 01:47 AM, Robert Edmonds wrote:
> Russ Allbery wrote:
>> Robert Edmonds writes:
>>
>>> However, that was two years ago. How long should we be expected to
>>> continue maintaining sysvinit scripts?
>>
>> My understanding of the feeling of the TC at the time is
Steve Langasek writes ("Re: Is missing SysV-init support a bug?"):
> On Tue, Oct 18, 2016 at 08:11:21PM -0700, Russ Allbery wrote:
> > The reactions of others is not about the spelling difference, which is
> > obviously trivial. It's about the refusal to change, the insi
On Tue, Oct 18, 2016 at 08:11:21PM -0700, Russ Allbery wrote:
> You will find that when you point out the correct spelling to those who
> use this one, the response is not "oh, whoops," like it would be for a
> mistake. Rather, it's usually a rant of surprising vitriol, a bunch of
> bizarrely
Cameron Norman writes:
> Those reading so much into such a small and understandable
> capitalization mistake (SystemV -> SystemD) should learn to take
> themselves less seriously and view things from different perspectives.
You will find that when you point out the
On Oct 18 2016, Cameron Norman wrote:
> On Tue, Oct 18, 2016 at 11:23 AM, Lars Wirzenius wrote:
>> On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
>>> If that is the case then they have enbedded hostility into their name simply
>>> becaus eit offends
On Tue, Oct 18, 2016 at 11:23 AM, Lars Wirzenius wrote:
> On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
>> If that is the case then they have enbedded hostility into their name simply
>> becaus eit offends normal grammar roles.
>
> I don't that's it at all.
>
> The reason many
On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
> If that is the case then they have enbedded hostility into their name simply
> becaus eit offends normal grammar roles.
I don't that's it at all.
The reason many people react to the SystemD spelling is becuase, for
some years now, trolls use
Not subscribed so this will break threading.
On 2016-10-17 at 17:53, Bart Schouten wrote:
I would consider that bigotry as SystemD is short pretty much for
System Daemon.
While this is a reasonable point, it doesn't invalidate Nikolas' point:
that the people behind the systemd project A:
On 2016-10-17 at 17:53, Bart Schouten wrote:
> Nikolaus Rath schreef op 17-10-2016 18:26:
>
>> On Oct 17 2016, Bart Schouten wrote:
>>
>>> (And I write SystemD with caps because that makes it easier to
>>> read, people invented capitals for a reason).
>>
>> What would you
Adam D. Barratt schreef op 17-10-2016 17:38:
On 2016-10-17 16:04, Bart Schouten wrote:
I also want to just quickly summarize my position here, since some
very long posts were written on this and linked into the thread by
someone.
And you then wrote another very long post. We really don't need
Nikolaus Rath schreef op 17-10-2016 18:26:
On Oct 17 2016, Bart Schouten wrote:
(And I write SystemD with caps because that makes it
easier to read, people invented capitals for a reason).
What would you think some people consistently spelled your name as Bart
SchouteN
On Oct 17 2016, Bart Schouten wrote:
> (And I write SystemD with caps because that makes it
> easier to read, people invented capitals for a reason).
What would you think some people consistently spelled your name as Bart
SchouteN with the same justification?
And if that set
On 2016-10-17 16:04, Bart Schouten wrote:
I also want to just quickly summarize my position here, since some
very long posts were written on this and linked into the thread by
someone.
And you then wrote another very long post. We really don't need another
one.
Regards,
Adam
I also want to just quickly summarize my position here, since some very
long posts were written on this and linked into the thread by someone.
I have only three issues with SystemD in order of diminishing
importance:
1) it is very hard to get up to speed with systemd, you run up against
I just want to respond after all this time because I ignored this debate
as I hadn't had time for it.
Russ you state in the email of 30-08 that you wish people would realize
the nuances between a system that can do one thing and a system that can
do another thing and both have advantages, and
On Sat, 2016-09-03 at 21:01 +0100, Jonathan de Boyne Pollard wrote:
[stuff]
btw, I'm sure I'm not the only one irritated by this, but when replying
to a message it is conventional to indicate such in the Subject header
(e.g. with the addition of an "Re:"), unless one is changing the subject
-
* Adam Borowski , 2016-09-03, 22:40:
* https://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run
I'm afraid your page is not working, on any of: Firefox, Chromium, Edge:
there's both a certificate name mismatch, then wrongly configured SNI.
Of course, dropping the
On Sat, Sep 03, 2016 at 01:11:52PM +0100, Jonathan de Boyne Pollard wrote:
> * https://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run
I'm afraid your page is not working, on any of: Firefox, Chromium, Edge:
there's both a certificate name mismatch, then wrongly configured SNI.
Of
Gerrit Pape:
To me too this readiness IPC ideas and implementations look
over-engineered.
A good convention for service programs would be to functionally test
for services it needs very early on startup, and fail if dependencies
are not available. The service supervisor (any modern init
Gerrit Pape:
My suggestion was and still is to separate services from programs on
the package level, [...]
I vaguely remember from the systemd packaging Hoo-Hah someone else
advocating this idea. I don't recall who it was off the top of my head.
Gerrit Pape:
I was not successful to
]] Gerrit Pape
> A good convention for service programs would be to functionally test for
> services it needs very early on startup, and fail if dependencies are
> not available. The service supervisor (any modern init scheme seems to
> now support this) relaunches eventually, until all
Adam Borowski, on Fri 02 Sep 2016 05:30:10 +0200, wrote:
> Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not)
Err, here:
* aterm: -
* Eterm: -
* gnome-terminal: +
* konsole: +
* lxterm: +
* lxterminal: -
* mlterm: +
* pterm: -
* roxterm: +
* rxvt-unicode: +
* screen:
On Fri, 02 Sep 2016 05:30:10 +0200, Adam Borowski wrote:
> Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not)
> * rxvt-unicode: -
FWIW, works for me (rxvt-unicode-256color).
Might be a font (configuration) issue, the 'b' looks interesting
here.
Cheers,
gregor
--
On Fri, 2 Sep 2016 05:30:10 +0200, Adam Borowski wrote:
> What "wide range of terminals that /can/ /do/ /italics/" do you mean?
>
> Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not)
> * linux console:- (text does nothing, fb makes it green)
> *
On Thu, Sep 01, 2016 at 10:09:42AM +0100, Jonathan de Boyne Pollard wrote:
> Like fulfilling the 1970s Unix promise of italics in manual pages, on the
> wide range of terminals that /can/ /do/ /italics/: stymied on Debian and
> only documented by a note at the bottom of a closed and forgotten bug
On Mon, Aug 29, 2016 at 09:47:53PM +0200, Simon Richter wrote:
> On 28.08.2016 22:11, Bart Schouten wrote:
> > That "very serious race condition" is nothing more than one daemon
> > having to wait for the other while starting up. THAT'S IT. Oh and
> > knowing when something has died so you can
On Fri, Aug 26, 2016 at 12:11:13AM +0200, Sven Hartge wrote:
> I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which
> has as a change
>
> * [917beed] conntrackd: get rid of the sysvinit support
>
> and I wondered, if this is a bug (and at what severity) or not.
Hi, something
Russ Allbery:
But change sucks, and part of what accreted was decades of subtle
workarounds to poorly-documented issues for which we have minimal
institutional memory.
Like fulfilling the 1970s Unix promise of italics in manual pages, on
the wide range of terminals that /can/ /do/
On Aug 29 2016, Russ Allbery wrote:
> Nikolaus Rath writes:
>> On Aug 28 2016, Bart Schouten wrote:
>
>>> But that's not the relevance. The idea that systemd is clearly superior
>>> to sysvinit is just something you concoct up because you
Russ,
On Tue, Aug 30, 2016 at 01:24:44AM -0700, Russ Allbery wrote:
[...]
> It's kind of a perfect storm. It makes sense if you sit down and
> enumerate the reasons, but it's still kind of amazing just how much of a
> perfect storm it is.
*g*
[...]
> TL;DR: I fear this init system is going to
[2016-08-29 18:30] Russ Allbery
>
> part text/plain1918
> Dmitry Bogatov writes:
>
> > Socket is not bad thing. Inventing daemon for no reason is complicating
> > things for no reason => bad. Thanks history, we have pid files, not
Marc Haber writes:
> Russ Allbery wrote:
>> Debian historically tries to handle these situations by just providing
>> everything simultaneously. The debate over init systems is as heated
>> as it is because it's quite difficult to do a good job at
On Mon, 29 Aug 2016 20:18:49 -0700, Russ Allbery
wrote:
>Debian historically tries to handle these situations by just providing
>everything simultaneously. The debate over init systems is as heated as
>it is because it's quite difficult to do a good job at supporting multiple
Nikolaus Rath writes:
> On Aug 28 2016, Bart Schouten wrote:
>> But that's not the relevance. The idea that systemd is clearly superior
>> to sysvinit is just something you concoct up because you don't know how
>> to write a service file or script and you
On Aug 28 2016, Bart Schouten wrote:
> But that's not the relevance. The idea that systemd is clearly
> superior to sysvinit is just something you concoct up because you
> don't know how to write a service file or script and you want to let
> systemd do the hard work.
How is
Hi,
On 28.08.2016 14:29, Jonathan de Boyne Pollard wrote:
> especially in light of the fact
> that the systemd developers have had a list of "Oddball things that you
> can actually do with rc scripts that systemd isn't going to support."
The crux of the matter is that what the majority thinks
Dmitry Bogatov writes:
> Socket is not bad thing. Inventing daemon for no reason is complicating
> things for no reason => bad. Thanks history, we have pid files, not
> `libpid' to talk to `pidd'.
Uh, the daemon in question is the init daemon? Which has been there
> > I can understand this need, although never needed it myself.
>
> > But implementation makes me sad. Instead of creating UNIX-way solution
> > (create /var/run/foo.ready, when you are ready?), it does the worst
> > thing I can imagine.
>
> If communicating with another local daemon via a UNIX
Hi,
On 28.08.2016 22:11, Bart Schouten wrote:
> That "very serious race condition" is nothing more than one daemon
> having to wait for the other while starting up. THAT'S IT. Oh and
> knowing when something has died so you can restart it or something.
That is also something the init system can
Vincent Bernat writes:
> ❦ 29 août 2016 05:00 CEST, Russ Allbery :
>> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
>> little less clean: the process sends itself a SIGSTOP when it's ready,
>> and then lets the init system send it a
Dmitry Bogatov writes:
> I can understand this need, although never needed it myself.
> But implementation makes me sad. Instead of creating UNIX-way solution
> (create /var/run/foo.ready, when you are ready?), it does the worst
> thing I can imagine.
If communicating
The fun thing is that if the original poster had just shipped an
half-broken script nobody would have ever noticed, and in a couple of
years it would have been another data point about the irrelevance of
sysvinit nowadays.
As long as the package builds, don't bother... :-)
--
ciao,
Marco
"Adam D. Barratt" writes:
> No. Policy is not a user-focused tool, it's the documentation of how
> developers / maintainers are expected to build packages. It documents
> how things are and the current conventions, not how they will or might
> be at some hypothetical
On Mon, 2016-08-29 at 13:12 +0300, Dmitrii Kashin wrote:
> Don Armstrong writes:
[...]
> > Policy is not a tool to beat developers with; it's a method of
> > documenting convention so that we can build a distribution of packages
> > which interact. Like most documentation of
Didier 'OdyX' Raboud writes:
> Le lundi, 29 août 2016, 12.07:23 h CEST Dmitrii Kashin a écrit :
>> But I know a lot of them. And not only in Debian community. And they
>> don't agree that migrating will give them greater control over their
>> systems.
>
> This is not a
Le lundi, 29 août 2016, 12.07:23 h CEST Dmitrii Kashin a écrit :
> But I know a lot of them. And not only in Debian community. And they
> don't agree that migrating will give them greater control over their
> systems.
This is not a popularity contest, in which we'd count points either way. We,
Don Armstrong writes:
> On Mon, 29 Aug 2016, Dmitrii Kashin wrote:
>> If we assume that this precedent allow a maintainer to violate policy,
>> so we don't need the Policy anymore.
>
> Violating policy is still a bug; it may be a bug in policy, or a bug in
> the package.
>
>>
On Mon, 29 Aug 2016, Dmitrii Kashin wrote:
> If we assume that this precedent allow a maintainer to violate policy,
> so we don't need the Policy anymore.
Violating policy is still a bug; it may be a bug in policy, or a bug in
the package.
> they still continue to rely on Policy to be sure that
But I know a lot of them. And not only in Debian community. And they
don't agree that migrating will give them greater control over their
systems.
If you want I'll ask them to write here too.
Attila Kinali writes:
> On Thu, 25 Aug 2016 19:47:55 -0400
> Robert Edmonds
Philipp Kern writes:
> On 2016-08-26 19:53, Wookey wrote:
>> After Stretch there may not be that many sysvinit users, but I think
>> that 2 releases is the minimum sensible period to maintain support for
>> such a siginificant change.
>
> But it seems that this discussion does
[2016-08-28 20:00] Russ Allbery
>
> part text/plain3207
> Dmitry Bogatov writes:
>
> > Not to start flame or to advertize anything/anyone, but why to integrate
> > with 'runit' init system, your program should support foreground
> >
❦ 29 août 2016 05:00 CEST, Russ Allbery :
> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
> little less clean: the process sends itself a SIGSTOP when it's ready, and
> then lets the init system send it a SIGCONT. This does work, but I don't
> like it
Dmitry Bogatov writes:
> Not to start flame or to advertize anything/anyone, but why to integrate
> with 'runit' init system, your program should support foreground
> operation and logging on stdout, and to integrate with systemd, it
> should link with library?
You
On 2016-08-28 16:11, Bart Schouten wrote:
Unnamed issues that are made to appear HUGE. And they are so simple
and so small, a child could do it. (I like did that sort of thing when
I was 14 or 15). (But it was like assembler and pascal and writing
interrupt handlers and being awesome ;-)).
[2016-08-28 06:26] Adam Borowski
>
> part text/plain2020
> On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > > I hugely support idea of dynamically loading libsystemd.
> > >
> > > Please don't, no. While I do think packages should
]] Bart Schouten
> You will now demonstrate your superiority by claiming you know the
> better spelling?
It has nothing to do with superiority. It's just that it's a tad tiring
to see it misspelled, just like it gets tiring to see people write
Micro$oft and other similar «funny» misspellings.
Andrey Rahmatullin schreef op 28-08-2016 22:06:
On Sun, Aug 28, 2016 at 09:23:58PM +0200, Bart Schouten wrote:
> You'll be doing yourself a favour. For better or for worse, the
> mis-spelling has become a shibboleth by which people tend to recognize
> mischievous pot-stirrers at a glance.
Oh
Philipp Kern schreef op 28-08-2016 12:41:
http://ral-arturo.blogspot.com/2016/08/why-conntrackd-in-debian-is-better-with.html
I am sorry I allowed myself to be drawn into this.
That "severely broken init script" is thus nothing more serious than any
other script out there, and the "very bad
On Sun, Aug 28, 2016 at 09:23:58PM +0200, Bart Schouten wrote:
> > You'll be doing yourself a favour. For better or for worse, the
> > mis-spelling has become a shibboleth by which people tend to recognize
> > mischievous pot-stirrers at a glance.
>
> Oh please.
>
> You will now demonstrate
Jonathan de Boyne Pollard schreef op 28-08-2016 13:56:
Bart Schouten:
Personally I do not run a non-SystemD system, [...]
Then please spell the name correctly. It is no more "SystemD" than
inetd is "INetD" or rsyslogd is "RSysLogD". It is "systemd".
You'll be doing yourself a favour. For
Arturo Borrero González:
* systemd is starting to drop support for some sysvinit mechanisms
[https://sources.debian.net/src/systemd/231-4/debian/systemd.NEWS/]
Don't employ such thinking. It is a mistake; in two ways no less.
Close on the heels of the Debian Technical Committee's decision
Bart Schouten:
Personally I do not run a non-SystemD system, [...]
Then please spell the name correctly. It is no more "SystemD" than
inetd is "INetD" or rsyslogd is "RSysLogD". It is "systemd".
You'll be doing yourself a favour. For better or for worse, the
mis-spelling has become a
On 2016-08-26 19:53, Wookey wrote:
After Stretch there may not be that many sysvinit users, but I think
that 2 releases is the minimum sensible period to maintain support for
such a siginificant change.
But it seems that this discussion does not consider if sysvinit support
in the conntrackd
Robert Edmonds:
The relevant text from the policy manual, §9.11: [...]
The Debian Policy Manual never got updated in the wake of the Debian
systemd Hoo-Hah. It remains written from the viewpoint that System 5
init and rc are the defaults, and that upstart is a novelty addendum.
Several
Robert Edmonds:
The relevant text from the policy manual, §9.11: [...]
Ansgar Burchardt:
Was that changed since the default init system was changed? It pretty
much still reads like Policy still assumes that sysvinit is the
default init system. It also still mentions upstart in 9.11.1;
On Fri, Aug 26, 2016 at 08:10:19PM +0500, Andrey Rahmatullin wrote:
> On Fri, Aug 26, 2016 at 02:26:53PM +0100, Ian Jackson wrote:
> > > The rationale for the change was:
> > > * sysvinit conntrackd script is really poor, to reliably use
> > >conntrackd as a systemd daemon you should use
On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think
Holger Levsen schreef op 26-08-2016 14:16:
So, obviously from my point of view, lack of sysvinit support is not a
bug.
And policy supports your view, considering the above (*) are
"compelling
reasons" to do so.
(*) and the fact that conntrackd is linux only…
Personally I do not run a
Dmitry Bogatov writes:
> You convinced me. If I pursue simplicity, it would be better to just
> recompile packages to get rid of unwanted dependencies.
I strongly suspect the amount of time you have spent participating in this
thread already exceeds all benefit you will ever
On Sat, Aug 27, 2016 at 07:36:02AM -0400, The Wanderer wrote:
> There is one minor/cosmetic downside of libsystemd as currently
> provided, however: the apt-listchanges changelog.
>
> The only '*systemd*' package which I have installed is libsystemd0.
> However, whenever I dist-upgrade (which is
On 2016-08-27 at 06:26, Andrew Shadura wrote:
> On 27 August 2016 at 10:33, Dmitry Bogatov wrote:
>
>> Like compat package, which provides libsystemd.a static library
>> and headers, that mirrors interface of libsystemd. This library
>> would forward call to actual libsystemd,
> Once per thread about systemd, I point out that dbus-daemon links to both
> libapparmor and libselinux - which results in at least one useless library
> for literally everyone with dbus installed, since "major" LSMs don't
> stack, so nobody can possibly be using both AppArmor and SELinux at the
On Sat, 27 Aug 2016 at 10:33:36 +0300, Dmitry Bogatov wrote:
>
> > > > * conntrackd & systemd are very good integrated (using libsystemd)
> > >
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as
On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think
> > > * conntrackd & systemd are very good integrated (using libsystemd)
> >
> > I hugely support idea of dynamically loading libsystemd.
>
> Please don't, no. While I do think packages should keep sysvinit
> support as long as it continues to work and doesn't make other paths
> worse, I don't
Dmitry Bogatov wrote:
> Arturo Borrero Gonzalez wrote:
> > * conntrackd & systemd are very good integrated (using libsystemd)
>
> I hugely support idea of dynamically loading libsystemd.
Please don't, no. While I do think packages should keep sysvinit
support as long as it continues to work
On Thu, 25 Aug 2016 19:47:55 -0400
Robert Edmonds wrote:
> I would guess that the vast majority of folks still using sysvinit with
> Debian are running wheezy or older, and thus removing sysvinit scripts
> from packages in unstable wouldn't affect them. But maybe that still
>
On Fri, 2016-08-26 at 18:39 +0200, Christoph Anton Mitterer wrote:
> On Fri, 2016-08-26 at 17:07 +0100, Adam D. Barratt wrote:
> > No. It shows that, two years ago, over 18,000 machines that were
> > reporting to the popcon servers had sysvinit-core installed and now
> > less
> > than a third of
On 2016-08-25 19:47 -0400, Robert Edmonds wrote:
> Russ Allbery wrote:
> > Robert Edmonds writes:
> I would guess that the vast majority of folks still using sysvinit with
> Debian are running wheezy or older, and thus removing sysvinit scripts
> from packages in unstable
1 - 100 of 126 matches
Mail list logo