On Sat, Aug 08, 2015 at 02:38:48AM -0500, T.J. Duchene wrote:
> You could always lift scripts from Wheezy and use them as a template.
Or even from jessie, now that Debian jessie in stable.
-- hendrik
>
> On Sat, Aug 8, 2015 at 2:28 AM, Miles Fidelman
> wrote:
>
> > T.J. Duchene wrote:
> >
> >
On Sat, 08 Aug 2015 09:46:07 +0200
Jaromil wrote:
>
>
> On 8 August 2015 09:28:42 CEST, Miles Fidelman
> wrote:
>
> >If, instead, they start removing the sysv scripts, and including
> >homebrew systemd units - then we're in for a mess of rework.
>
> both me, Franco and other VUAs are litera
On Sat, Aug 08, 2015 at 09:43:47AM +0200, Laurent Bercot wrote:
> On 08/08/2015 03:43, Isaac Dunham wrote:
> >Which, fortunately, is pretty easy to do: I wrote an environment
> >sanitizer yesterday, because I was curious how easily solved that is.
> >Usage is
> >cautenv [-c DIR] [-u] [-x] COMMAND [
Jaromil wrote:
Jaromil wrote:
Its early to say, but this thread is just prospecting. I believe that
on a longer term we can hardly do worse tha Debian when untangling
dependencies that right now constantly drag in desktop oriented
stuff, like avahi and other similar nonsense that we almost got u
Miles Fidelman writes:
> Rainer Weikusat wrote:
[...]
>> Also, to re-iterate this: What an init script needs to do is really only
>> 'start a process'/ 'stop a process'. Most of the other code which crept
>> in there during the last 15 - 20 years will fall into one of two
>> categories
>>
>>
On Sat, 8 Aug 2015 11:03:34 +0200
Jaromil wrote:
>
> > Jaromil wrote:
>
> > >Its early to say, but this thread is just prospecting. I believe that
> > >on a longer term we can hardly do worse tha Debian when untangling
> > >dependencies that right now constantly drag in desktop oriented
> > >st
Isaac Dunham writes:
> On Thu, Aug 06, 2015 at 05:14:28PM +0200, Laurent Bercot wrote:
>> On 06/08/2015 16:31, Isaac Dunham wrote:
>> >If differences in environment can cause problems, it's a problem with
>> >design. A program that changes what it does just due to differences
>> >between the init
> Jaromil wrote:
> >Its early to say, but this thread is just prospecting. I believe that
> >on a longer term we can hardly do worse tha Debian when untangling
> >dependencies that right now constantly drag in desktop oriented
> >stuff, like avahi and other similar nonsense that we almost got use
Jaromil wrote:
On 8 August 2015 09:28:42 CEST, Miles Fidelman
wrote:
If, instead, they start removing the sysv scripts, and including
homebrew systemd units - then we're in for a mess of rework.
both me, Franco and other VUAs are literally aiming to a fork, either after
Jessie or Ascii as i
But now we're back into having to have a completely separate package
repository, along with a full set of package maintainers. Sigh.
T.J. Duchene wrote:
You could always lift scripts from Wheezy and use them as a template.
On Sat, Aug 8, 2015 at 2:28 AM, Miles Fidelman
mailto:mfidel...@m
On 8 August 2015 09:28:42 CEST, Miles Fidelman
wrote:
>If, instead, they start removing the sysv scripts, and including
>homebrew systemd units - then we're in for a mess of rework.
both me, Franco and other VUAs are literally aiming to a fork, either after
Jessie or Ascii as infrastructure
On 08/08/2015 03:43, Isaac Dunham wrote:
Which, fortunately, is pretty easy to do: I wrote an environment
sanitizer yesterday, because I was curious how easily solved that is.
Usage is
cautenv [-c DIR] [-u] [-x] COMMAND [COMMAND_ARGS...]
Would you mind linking it ? I'm interested in trying to
You could always lift scripts from Wheezy and use them as a template.
On Sat, Aug 8, 2015 at 2:28 AM, Miles Fidelman
wrote:
> T.J. Duchene wrote:
>
>>
>>
>> On 08/07/2015 09:31 PM, Miles Fidelman wrote:
>>
>>>
>>> Trivial as in, somebody has to do it. The whole point of packaging is
>>> to auto
T.J. Duchene wrote:
On 08/07/2015 09:31 PM, Miles Fidelman wrote:
Trivial as in, somebody has to do it. The whole point of packaging
is to automate a lot of the routine things involved in installation.
And, because Debian (and presumeably Devuan) don't put stuff in
default locations, pac
On 08/07/2015 09:31 PM, Miles Fidelman wrote:
Trivial as in, somebody has to do it. The whole point of packaging is
to automate a lot of the routine things involved in installation.
And, because Debian (and presumeably Devuan) don't put stuff in
default locations, packaging involves chang
Rainer Weikusat wrote:
Miles Fidelman writes:
Rainer Weikusat wrote:
Miles Fidelman writes:
Alexey Rochev wrote
*Date: *2015-08-05 07:29 -400
*To: *dng
*Subject: *[DNG] Init scripts in packages
Currently Debian packages contains both systemd units and init scripts.
However, Debian develope
On Thu, Aug 06, 2015 at 05:14:28PM +0200, Laurent Bercot wrote:
> On 06/08/2015 16:31, Isaac Dunham wrote:
> >If differences in environment can cause problems, it's a problem with
> >design. A program that changes what it does just due to differences
> >between the init environment and a login envi
>James Powell Thu, 06 Aug 2015 01:02:56 -0700
>Currently Debian packages contains both systemd units and init scripts.
>However, Debian developers refused to support several init systems. So it's
>only a matter of time when they remove init scripts from packages.What will
>Devuan developers do
- Original Message -
> From: "Rainer Weikusat"
> Miles Fidelman writes:
>> Worse, if "refuse to support multiple init systems" means that the
>> Debian packagers start stripping out the init scripts from Debian
>> packages, those, those packages become useless in Devuan.
>
> This is act
Miles Fidelman writes:
> Rainer Weikusat wrote:
>> Miles Fidelman writes:
>>
>>> Alexey Rochev wrote
*Date: *2015-08-05 07:29 -400
*To: *dng
*Subject: *[DNG] Init scripts in packages
Currently Debian packages contains both systemd units and init scripts.
However, Debian d
tilt! writes:
[...]
> Laurent Bercot wrote on 06/08/2015 at 14:21 CEST:
>> [...]
>> And "status". This is very service-dependent: since there is no
>> global API, no service manager, scripts will query the daemon's
>> status in a daemon-specific way. More vagueness again, because
>> "status" d
Rainer Weikusat wrote:
Miles Fidelman writes:
Alexey Rochev wrote
*Date: *2015-08-05 07:29 -400
*To: *dng
*Subject: *[DNG] Init scripts in packages
Currently Debian packages contains both systemd units and init scripts.
However, Debian developers refused to support several init
systems. So it
I'm not sure how systemd does it, but in my vision, there should be
two different states for the service: the *wanted* state, and the
*current* state.
The wanted state is what is set by the administrator when she runs
a command such as "rc thisrunlevel". The command should set all the
services
Apologies, a typo:
I wrote myself on 07/08/2015 at 15:21 CEST:
[...]
* the status is "failed" (the service is *NOT* alive, and this
is due to it having failed to start on a previous attempt
to do so).
My question is, did I understand that correctly?
[...]
Kind regards.
Hi,
sorry for picking up on this edge while the thread's general
discussion has advanced further.
The "status" command matters to me; that is why I would like
to address its handling in a more detailed manner.
Laurent Bercot wrote on 06/08/2015 at 14:21 CEST:
[...]
And "status". This is very
Miles Fidelman writes:
> Alexey Rochev wrote
>> *Date: *2015-08-05 07:29 -400
>> *To: *dng
>> *Subject: *[DNG] Init scripts in packages
>> Currently Debian packages contains both systemd units and init scripts.
>> However, Debian developers refused to support several init
>> systems. So it's
>> o
Simplification of init scripts can be done by replacing them with a
text file containing the following:
a) preliminary logic tests to verify whether daemon can be started
b) command to start daemon together with parameters
c) command to stop daemon with parameters if applicable
Only two lines will
Alexey Rochev wrote
*Date: *2015-08-05 07:29 -400
*To: *dng
*Subject: *[DNG] Init scripts in packages
Currently Debian packages contains both systemd units and init scripts.
However, Debian developers refused to support several init systems. So
it's
only a matter of time when they remove init s
On 07/08/2015 00:09, Rainer Weikusat wrote:
Since this is maybe/ likely a bit harsh
Not harsh, just unwilling to accept that I'm actually your ally and
not your enemy.
I'm not trying to replace Unix, because Unix is not broken - at least,
not as far as system startup is concerned. There *are
Am 06.08.2015 17:49 schrieb Steve Litt:
Laurent Bercot wrote:
I have never said, am not saying, and probably never will say that
systemd is any good. It's not, and Lennart and Kay should go back to
engineering school,
:s/engineering school/kindergarten/
Hell no, that wouldn't be good for
Rainer Weikusat writes:
[...]
> I'm going to ignore the remainder of this because - while system startup
> is a topic of some interest to me - people warring over the right way to
> replace UNIX(*) because it's broken isn't.
Since this is maybe/ likely a bit harsh (and I'm trying to rid myself
Rainer Weikusat writes:
> Laurent Bercot writes:
>> On 06/08/2015 20:18, Rainer Weikusat wrote:
>>> UNIX(*) and therefore, Linux, provides two system calls named fork and
>>> exec which can be used to create a new process while inheriting certain
>>> parts of the existing environment and to execu
Laurent Bercot writes:
> On 06/08/2015 20:18, Rainer Weikusat wrote:
>> UNIX(*) and therefore, Linux, provides two system calls named fork and
>> exec which can be used to create a new process while inheriting certain
>> parts of the existing environment and to execute a new program in an
>> exist
On 06/08/2015 20:18, Rainer Weikusat wrote:
UNIX(*) and therefore, Linux, provides two system calls named fork and
exec which can be used to create a new process while inheriting certain
parts of the existing environment and to execute a new program in an
existing process, keeping most of the env
Laurent Bercot writes:
A leading remark: This is based on an existing system I have implemented
(originally for Debian 5) working in the described way. The code is
proprietary as I'm one of those evil guys who want to (and do) write code
for a living despite the 'free software community' traditio
On Thu, 6 Aug 2015 16:41:38 +0200
Laurent Bercot wrote:
> I have never said, am not saying, and probably never will say that
> systemd is any good. It's not, and Lennart and Kay should go back to
> engineering school,
:s/engineering school/kindergarten/
/* Litt ducks and runs */
__
On Thu, 06 Aug 2015 10:28:47 +0100
Rainer Weikusat wrote:
> But a bare-bones init script does really only three things:
>
> 1. Execute a command to start something.
> 2. Execute a command which stops it again.
> 3. Execute 2) then 1) for a restart.
Those are easy. The tough part is process depe
On Thu, 06 Aug 2015 15:00:20 +0100
Rainer Weikusat wrote:
> Laurent Bercot writes:
> > There's a simple reason for that: "init scripts" aren't
> > "managing services". They can more or less start and stop them,
> > that's about it - and they're not even doing the starting and
> > the stopping
On Thu, 06 Aug 2015 15:00:20 +0100
Rainer Weikusat wrote:
> 'Winning' against systemd will require getting support of a
> commerically more potent company than RedHat and SuSE combined and one
> willing to sink a sizable amount of money into the task.
The day I believe the preceding sentence
On 06/08/2015 16:31, Isaac Dunham wrote:
If differences in environment can cause problems, it's a problem with
design. A program that changes what it does just due to differences
between the init environment and a login environment is going to be
hard to debug.
There are tons of those, and you
On 06/08/2015 16:00, Rainer Weikusat wrote:
That's all nice and dandy but it all boils down to 'the code executed by
the init script was deficient in some way'.
Yes, just like root exploits boil down to "the code executed by the
suid program was deficient in some way".
My point is that you sh
On Thu, Aug 06, 2015 at 02:21:55PM +0200, Laurent Bercot wrote:
> On 06/08/2015 11:45, tilt! wrote:
> >Thing is, init scripts tend to have problems managing services
> >that do not offer sufficient commandline interfaces as described
> >above
>
> There's a simple reason for that: "init scripts" a
Laurent Bercot writes:
> On 06/08/2015 11:45, tilt! wrote:
>> Thing is, init scripts tend to have problems managing services
>> that do not offer sufficient commandline interfaces as described
>> above
>
> There's a simple reason for that: "init scripts" aren't
> "managing services". They can mo
"tilt!" writes:
> On 08/06/2015 11:28 AM, Rainer Weikusat wrote:
>> [...]
>> But a bare-bones init script does really only three things:
>>
>> 1. Execute a command to start something.
>> 2. Execute a command which stops it again.
>> 3. Execute 2) then 1) for a restart.
>
> There are additional act
On 06/08/2015 11:45, tilt! wrote:
Thing is, init scripts tend to have problems managing services
that do not offer sufficient commandline interfaces as described
above
There's a simple reason for that: "init scripts" aren't
"managing services". They can more or less start and stop them,
that's
On 08/06/2015 11:28 AM, Rainer Weikusat wrote:
[...]
But a bare-bones init script does really only three things:
1. Execute a command to start something.
2. Execute a command which stops it again.
3. Execute 2) then 1) for a restart.
There are additional actions required by [LSB]; out of these
Alexey Rochev writes:
> Currently Debian packages contains both systemd units and init scripts.
> However, Debian developers refused to support several init systems. So it's
> only a matter of time when they remove init scripts from packages.
This would rid the world of a lot of code of very dubi
On 05/08/15 23:29, Alexey Rochev wrote:
Currently Debian packages contains both systemd units and init
scripts. However, Debian developers refused to support several init
systems. So it's only a matter of time when they remove init scripts
from packages. What will Devuan developers do when it hap
Currently Debian packages contains both systemd units and init scripts.
However, Debian developers refused to support several init systems. So it's
only a matter of time when they remove init scripts from packages.What will
Devuan developers do when it happens? We can use sysvinit and Devuan bec
49 matches
Mail list logo
