On 02/28/2014 01:10 AM, Tom H wrote:
>> Just to name a few:
>> - getting rid of the ugly LSB headers
>
> Beauty is in the eye of the beholder. The "Short-Description" and
> "Description" LSB fields are useless, but I don't find Debian's LSB
> headers and Gentoo's squiggle-delimited stanzas any mor
On 02/24/2014 04:29 AM, Marco d'Itri wrote:
> On Feb 23, Thomas Goirand wrote:
>
>> Marco and yourself are *a way* off topic. Please at least have the
>> decency to rename the subject of the tread to "systemd fanboys flamewar
>> yet-again bashing OpenRC just for fun" or something similar (but
>>
Dear Kevin,
Kevin Chadwick writes:
> The benefit that Linux and even firefox etc. has gained from OpenBSD's
> practically paranoid bug fixing as well as finding the bugs for all the
> platforms it's userland still runs on especially in compiler tools
> should be realised and not underestimated.
Hey Adrian,
John Paul Adrian Glaubitz writes:
> That's correct. However, the problem with kFreeBSD is that I - as a
> package maintainer - have to invest extra time to make sure my
> packages don't FTBFS on these architectures as otherwise my packages
> wouldn't be allowed to migrate to testing.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/23/2014 03:29 PM, Marco d'Itri wrote:
> On Feb 23, Thomas Goirand wrote:
>
>> Marco and yourself are *a way* off topic. Please at least have the
>> decency to rename the subject of the tread to "systemd fanboys
>> flamewar yet-again bashing
On Feb 23, Thomas Goirand wrote:
> Marco and yourself are *a way* off topic. Please at least have the
> decency to rename the subject of the tread to "systemd fanboys flamewar
> yet-again bashing OpenRC just for fun" or something similar (but
> preferably: don't just do that in this list, and avo
previously on this list Kevin Chadwick contributed:
> Perhaps before this thread spirals out of control I should
should also mention this has been discussed on this very list already,
though before I was enrolled and the following response went
unreplied to.
On the other hand and I doubt of sig
previously on this list Matthias Urlichs contributed:
> One sample usecase where they dont't: "the system is wedged / overcommitted
> and I need to terminate some services; guess I'll start another ten processes
> to do that". Yeah, right.
>
> I'll be nice to everybody else here and not enumerate
Hi,
Kevin Chadwick:
> Regex works just fine for me.
>
One sample usecase where they dont't: "the system is wedged / overcommitted
and I need to terminate some services; guess I'll start another ten processes
to do that". Yeah, right.
I'll be nice to everybody else here and not enumerate any othe
On 02/21/2014 03:37 AM, Ondřej Surý wrote:
> mkdir -p /run/openrc
> touch /run/openrc/softlevel
>
> and then it still doesn't work as expected:
>
> root@howl:/etc/init.d# /etc/init.d/rsyslog start
> * WARNING: rsyslog is already starting
>
> root@howl:/etc/init.d# /etc/init.d/rsyslog stop
> *
On 02/23/2014 08:57 PM, John Paul Adrian Glaubitz wrote:
> On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote:
> >
> http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_da
Perhaps before this thread spirals out of control I should re-iterate
that what I said was cgroups doesn't pass the worth-it barrier for me
and not that they have NO value.
I also mentioned pgroups for those that do want this functionality but
also want portability and not bugs in daemons on one
previously on this list Marco d'Itri contributed:
> > But you aren't planning on running openrc at all, are you?
> Who is? Seriously, would you mind stepping forward?
If it was available I would use it but wouldn't be switching cgroups
on or would be switching them off even if I hadn't bothered
previously on this list Matthias Urlichs contributed:
> > Kevin, I don't think you understand the reasoning behind this. Again,
> > the problem the init system has to solve here is being able to track a
> > process with a 100% accuracy, so whatever automated mechanisms you have
> > configured when
On Fri, 21 Feb 2014 23:53:51 +0100
John Paul Adrian Glaubitz wrote:
> Kevin, I don't think you understand the reasoning behind this. Again,
> the problem the init system has to solve here is being able to track a
> process with a 100% accuracy, so whatever automated mechanisms you have
> configure
On Sun, Feb 23, 2014 at 08:45:10PM +0800, Thomas Goirand wrote:
> On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
> >
> >
> >> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz
> >> wrote:
> >>
> >> I agree and understand that this was the way to go back in the old
> >> days, but we shouldn't
On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote:
> http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> sysv-rc wins...
>
> With
On Sun, Feb 23, 2014 at 12:43:14PM +, Jonathan Dowland wrote:
> Since you aren't a user nor are going to be a user of openrc, I don't
> see why you feel the need to critique it, especially on debian-devel
> where the majority of subscribers are just not interested.
Well. OpenRC was up for disc
On 02/23/2014 07:36 PM, Marco d'Itri wrote:
> On Feb 23, Jonathan Dowland wrote:
>
>> But you aren't planning on running openrc at all, are you?
> Who is? Seriously, would you mind stepping forward?
>
> http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc&show_installed=on&
On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
>
>
>> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz
>> wrote:
>>
>> I agree and understand that this was the way to go back in the old
>> days, but we shouldn't be using that on current setups.
>
> But you aren't planning on running openrc
Please do not CC me, I am subscribed to the list.
On Sun, Feb 23, 2014 at 12:47:44PM +0100, John Paul Adrian Glaubitz
wrote:
> On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
> > But you aren't planning on running openrc at all, are you?
>
> No, and I don't see any compelling reason why I should.
On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
>> I agree and understand that this was the way to go back in the old
>> days, but we shouldn't be using that on current setups.
>
> But you aren't planning on running openrc at all, are you?
No, and I don't see any compelling reason why I should. W
On Feb 23, Jonathan Dowland wrote:
> But you aren't planning on running openrc at all, are you?
Who is? Seriously, would you mind stepping forward?
http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_da
> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz
> wrote:
>
> I agree and understand that this was the way to go back in the old
> days, but we shouldn't be using that on current setups.
But you aren't planning on running openrc at all, are you?
--
To UNSUBSCRIBE, email to debian-devel-
Hi,
John Paul Adrian Glaubitz:
> Kevin, I don't think you understand the reasoning behind this. Again,
> the problem the init system has to solve here is being able to track a
> process with a 100% accuracy, so whatever automated mechanisms you have
> configured when certain situations occur, they
On 02/21/2014 11:38 PM, Kevin Chadwick wrote:
> previously on this list hero...@gentoo.org contributed:
>
>>> And grepping through the output of "ps" or similar is not what
>>> I would consider reliable and robust either.
>>
>> Nod. grepping `ps` is what we should avoid at all cost.
>
> All cos
previously on this list hero...@gentoo.org contributed:
> > And grepping through the output of "ps" or similar is not what
> > I would consider reliable and robust either.
>
> Nod. grepping `ps` is what we should avoid at all cost.
All cost? While I like OpenRC and thanks to Gentoo for it and
Dear Adrian,
John Paul Adrian Glaubitz writes:
> On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
>>> So, OpenRC actually also relies on files - like System V Init - to
>>> track the state of a service? Isn't that approach somewhat unreliable
>>> and hacky?
>>
>> I bet you are going to tell me
On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
>> So, OpenRC actually also relies on files - like System V Init - to
>> track the state of a service? Isn't that approach somewhat unreliable
>> and hacky?
>
> I bet you are going to tell me the only reliable and non-hacky way to
> track the state
Dear Adrian,
John Paul Adrian Glaubitz writes:
> So, OpenRC actually also relies on files - like System V Init - to
> track the state of a service? Isn't that approach somewhat unreliable
> and hacky?
I bet you are going to tell me the only reliable and non-hacky way to
track the state of a ser
On 02/21/2014 04:20 AM, hero...@gentoo.org wrote:
> OpenRC needs a proper directory structure in /run/openrc to track the
> status of services. It is handled by init.sh and friends, you may need
> to hack that.
So, OpenRC actually also relies on files - like System V Init - to
track the state of a
On 20/02/14 19:37, Ondřej Surý wrote:
> I have split openrc into openrc and openrc-sysv moving the conflicting
> parts to openrc-sysv on my system, and it install just fine
If sysv-rc's invoke-rc.d and update-rc.d should be treated as generic
glue shared by multiple inits (which they probably shou
Hey Ondřej,
Ondřej Surý writes:
> I have split openrc into openrc and openrc-sysv moving the conflicting
> parts to openrc-sysv on my system, and it install just fine, but running
> script with /sbin/openrc-run needs:
>
> mkdir -p /run/openrc
> touch /run/openrc/softlevel
>
> and then it still d
On Thu, Feb 20, 2014, at 17:39, Thomas Goirand wrote:
> There's of course dependencies in OpenRC. You have the choice: either
> you keep the LSB headers, either you write it the OpenRC way (IMO,
> prefered...). In OpenRC, you just use functions of the openrc-run
> "interpreter". For example:
Well,
Ansgar Burchardt writes:
> On 02/20/2014 15:28, Thomas Goirand wrote:
>> Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
>> IMO important (is there anyone still working on sysv-rc apart from a
>> few Debian maintainers? my understanding is: we're alone now...).
> Doesn't
Ansgar Burchardt writes:
> On 02/20/2014 09:57, gregor herrmann wrote:
>> On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
>>> That package does currently depend on
>>> perl, though, which isn't appropriate for an essential package.
>>> ... The dependency is because
>>> deb-systemd-helper
On 02/20/2014 10:45 PM, Didier 'OdyX' Raboud wrote:
> Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
>> On 02/20/2014 09:02 PM, Tom H wrote:
>>> What features does sysvinit+openrc have that
>>> sysvinit+sysv-rc+insserv doesn't have?
>>
>> Just to name a few:
>> - getting rid of the ug
On 02/20/2014 15:28, Thomas Goirand wrote:
> On 02/20/2014 09:02 PM, Tom H wrote:
>> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
>> doesn't have?
>
> Just to name a few:
> - getting rid of the ugly LSB headers
> - cgroup supports to kill processes
I'm curious: does OpenR
Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
> On 02/20/2014 09:02 PM, Tom H wrote:
> > What features does sysvinit+openrc have that
> > sysvinit+sysv-rc+insserv doesn't have?
>
> Just to name a few:
> - getting rid of the ugly LSB headers
They might be ugly, but they encode the d
On 02/20/2014 09:02 PM, Tom H wrote:
> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
> doesn't have?
Just to name a few:
- getting rid of the ugly LSB headers
- cgroup supports to kill processes
- rc_hotplug (a hotplugged service is one started by a dynamic dev
manager when
On 02/20/2014 02:10 AM, Kevin Chadwick wrote:
> Do people use all those runlevels?
As much as I know, there's only 4 in use (using names of OpenRC here,
since OpenRC has named runlevels):
- shutdown (runlevel 0)
- recovery (runlevel 1)
- reboot (runlevel 6)
- default (often, everything else, but m
On Thu, 20 Feb 2014 10:52:12 +0100, Ansgar Burchardt wrote:
> On 02/20/2014 09:57, gregor herrmann wrote:
> > On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
> >> ... The dependency is because
> >> deb-systemd-helper uses a bunch of modules that are not currently in
> >> perl-core (File::
Hi,
On 02/20/2014 09:57, gregor herrmann wrote:
> On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
>> That package does currently depend on
>> perl, though, which isn't appropriate for an essential package.
>> ... The dependency is because
>> deb-systemd-helper uses a bunch of modules that
On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
> That package does currently depend on
> perl, though, which isn't appropriate for an essential package.
> ... The dependency is because
> deb-systemd-helper uses a bunch of modules that are not currently in
> perl-core (File::Path, File::B
hero...@gentoo.org writes:
> Forking was a decision made by me in the early phase of packaging
> OpenRC. At that time I referred to the way file-rc handled update-rc.d
> as in
> sysvinit: /usr/share/sysvinit/update-rc.d
> A central package providing update-rc.d and invoke-rc.d is nice. Thou
Hi Tollef,
Tollef Fog Heen writes:
> It's probably better to just contribute your changes to the sysv-rc
> version and so make that one able to manage openrc in addition to the
> others it already knows how to. No point in forking it.
Forking was a decision made by me in the early phase of pac
]] Thomas Goirand
> How come? I just took what was in the sysinit package! Or probably, what
> you are talking about is new features, which I should merge it back into
> the OpenRC version?
It's probably better to just contribute your changes to the sysv-rc
version and so make that one able to m
previously on this list Thomas Goirand contributed:
> So, systemd is still using /etc/rc?.d. Could you tell exactly what it
> uses out of /etc/rc?.d, and what for? Does it only needs to see them as
> S??script-name in runlevel 2 or 4 (or whatever it uses...)?
>
> If systemd needs links in /etc/rc
On Wed, Feb 19, 2014 at 03:45:12PM +, Dimitri John Ledkov wrote:
> On 19 February 2014 15:28, Ondřej Surý wrote:
> > are you aware that media are already quoting your blogpost as official
> > announcement of next Debian codename?
> >
>
> Nah, wasn't aware =) I blame Neil, I thought he still w
Hi,
The Wanderer:
> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> > manager ;-) Any reason, not to make it official? =)
>
> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports
On 02/19/2014 11:53 PM, Simon McVittie wrote:
> I suspect the right thing would be to share one implementation of
> update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
> supported init implementations, provided by either src:sysvinit or
> src:init-system-helpers.
Surprisingly, "serv
On 02/19/2014 10:47 PM, Michael Biebl wrote:
> Am 19.02.2014 00:52, schrieb Russ Allbery:
>> Henrique de Moraes Holschuh writes:
>>
>>> They *HAVE* to be provided by the active init system. They are an
>>> impedance matching layer (aka stable API) used by maintainer scripts to
>>> interface with
On 19 February 2014 15:57, The Wanderer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>
>> On 19 February 2014 15:28, Ondřej Surý wrote:
>>
>>> Dimitri,
>
>>> are you aware that media are already quoting your blogpost as
>>> offi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
> On 19 February 2014 15:28, Ondřej Surý wrote:
>
>> Dimitri,
>> are you aware that media are already quoting your blogpost as
>> official announcement of next Debian codename?
>
> Nah, wasn't a
On 19/02/14 15:09, Thomas Goirand wrote:
> First, yes, OpenRC uses /etc/runlevel, with the folders below that being
> the *names* of the runlevel (which IMO is a way more user friendly than
> just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
> everything-else=default. So we do have
On 19 February 2014 15:28, Ondřej Surý wrote:
> Dimitri,
>
> On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
>> On 19 February 2014 11:22, Neil McGovern wrote:
>> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McG
Dimitri,
On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
> On 19 February 2014 11:22, Neil McGovern wrote:
> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> >> > On Tue, Feb 18, 2014 at 07:18:30PM
On 02/19/2014 10:44 PM, Michael Biebl wrote:
> I'd like to add that switching to openrc breaks the SysV/LSB support in
> systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
> symlinks which signal if a service is active for a given runlevel.
> (those symlinks are created in /etc/r
Am 19.02.2014 00:52, schrieb Russ Allbery:
> Henrique de Moraes Holschuh writes:
>
>> They *HAVE* to be provided by the active init system. They are an
>> impedance matching layer (aka stable API) used by maintainer scripts to
>> interface with the active init system.
>
> If you look at the exi
Am 18.02.2014 19:18, schrieb Didier 'OdyX' Raboud:
> Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
>> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
>>> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
Once I consider OpenRC ready for it, would it be ok to jus
On 19 February 2014 11:22, Neil McGovern wrote:
> On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
>> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> > > [0] Can we haz a release name?
>> >
On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > > [0] Can we haz a release name?
> > >
> >
> > Sure. It's Debian 8.0, "zurg". [0]
> >
>
On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > [0] Can we haz a release name?
> >
>
> Sure. It's Debian 8.0, "zurg". [0]
>
> Neil
> [0] Note: may be a lie.
Umm, Debian 9.0?
--
"If you're not careful, t
Hi,
Thomas Goirand:
> > [0] Can we haz a release name?
>
> It's been years that I've been asking that we have the release name a
> way sooner. Ideally, one release earlier, so that we can prepare for the
> new name soon enough (and not fix things during the freeze). But the
> release team doesn't
Thomas Goirand writes:
> On 02/19/2014 08:05 AM, Henrique de Moraes Holschuh wrote:
>> On Tue, 18 Feb 2014, Russ Allbery wrote:
>>> There are some advantages to providing only one version with knowledge
>>> of all of the init systems given that we're supporting init system
>>> switching, and ther
Hi,
I'm replying to everyone in a single mail, I hope that's fine. I'm
therefore a bit repeating myself, sorry for that.
On 02/19/2014 02:18 AM, Didier 'OdyX' Raboud wrote:
> Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
>> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
>>> On
Apparently sysvinit scripts must be retained anyway for a smooth
migration to jessie; also for easy backporting of jessie packages to
wheezy, and maybe other reasons. Non-Linux ports are likely to use
those SysV init scripts, though we might invoke them from something
other than sysvinit.
I know
On Tue, 18 Feb 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
> > They *HAVE* to be provided by the active init system. They are an
> > impedance matching layer (aka stable API) used by maintainer scripts to
> > interface with the active init system.
>
> If you look at the exist
Henrique de Moraes Holschuh writes:
> They *HAVE* to be provided by the active init system. They are an
> impedance matching layer (aka stable API) used by maintainer scripts to
> interface with the active init system.
If you look at the existing implementation, you'll find that the version
pro
On Tue, 18 Feb 2014, Tollef Fog Heen wrote:
> > Once I consider OpenRC ready for it, would it be ok to just replace
> > sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>
> No, update-rc.d and invoke-rc.d still need to be provided by something.
They *HAVE* to be provided by t
On 02/18/2014 03:31 PM, Neil McGovern wrote:
> On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> [0] Can we haz a release name?
>>
> Sure. It's Debian 8.0, "zurg". [0]
finally one of the 'bad' guys!
[*] as a release, sid don't apply
>
> Neil
> [0] Note: may be a lie.
--
On Wed, Feb 19, 2014 at 01:11:21AM +0800, Thomas Goirand wrote:
> Actually, thinking about it a 2nd time, I think there would be a major
> drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
> then starting at the Jessie release, we don't have to care anymore about
> LSB header
Hello,
On Tue, 18 Feb 2014 19:59:13 +0100
Tollef Fog Heen wrote:
> > Once I consider OpenRC ready for it, would it be ok to just replace
> > sysv-rc by OpenRC, and transform sysv-rc into a transitional
> > package?
> No, update-rc.d and invoke-rc.d still need to be provided by
> something.
O
]] Thomas Goirand
> Once I consider OpenRC ready for it, would it be ok to just replace
> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
No, update-rc.d and invoke-rc.d still need to be provided by something.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky abo
On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> [0] Can we haz a release name?
>
Sure. It's Debian 8.0, "zurg". [0]
Neil
[0] Note: may be a lie.
signature.asc
Description: Digital signature
Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
> > On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
> >> Once I consider OpenRC ready for it, would it be ok to just replace
> >> sysv-rc by OpenRC, and transform sysv-r
Le mercredi, 19 février 2014, 01.11:21 Thomas Goirand a écrit :
> Actually, thinking about it a 2nd time, I think there would be a major
> drawback in delaying to Jessie +1. If we decide that sysv-rc goes
> away, then starting at the Jessie release, we don't have to care
> anymore about LSB header
Thomas Goirand writes:
> Actually, thinking about it a 2nd time, I think there would be a major
> drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
> then starting at the Jessie release, we don't have to care anymore about
> LSB header scripts. Meaning that we could write sy
On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote:
> Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is
On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is t
On Tue, Feb 18, 2014 at 05:26:05PM +0100, Christoph Egger wrote:
> Hm so why was none of the ports list Cc-ed on this mail? There is
> active discussion [0] between hurd and bsd people were we want to go
> now.
Likewise perhaps pkg-sysvinit-devel should be copied into all such
discussions (copie
On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote:
> Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is
Hi!
Ondřej Surý writes:
> I don't really want to open another can of worms, but what's the opinion
> of non-Linux ports maintainers on default init?
Hm so why was none of the ports list Cc-ed on this mail? There is
active discussion [0] between hurd and bsd people were we want to go
now.
> Or
On Tue, Feb 18, 2014 at 11:58:20PM +0800, Thomas Goirand wrote:
> You are IMO missing the point. I'm not proposing to drop support for
> init scripts, but remove sysv-rc. That's very different! We could
> continue to have init scripts but have OpenRC to use them.
Although I'm still not sure what p
On 02/18/2014 11:08 PM, Guus Sliepen wrote:
> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
>
>> On 02/18/2014 10:15 PM, Ondřej Surý wrote:
> [...]
>>> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
>>>
>>> Depends: systemd | openrc
>>>
>>> if I want to get rid of
On 18/02/14 14:15, Ondřej Surý wrote:
> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
>
> Depends: systemd | openrc
>
> if I want to get rid of non-declarative init scripts in my daemon
> packages?
I don't think that's going to be a good migration path from wheezy to
jessie. For
Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
> Once I consider OpenRC ready for it, would it be ok to just replace
> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
> What is the opinion of other DDs? Is there anyone which would like to
> keep the old featurele
Hello,
On 18 February 2014 16:08, Guus Sliepen wrote:
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is there anyone which would like to
>> keep the old featureles
On Tue, Feb 18, 2014 at 03:15:24PM +0100, Ondrej Surý wrote:
> Hi,
>
> I don't really want to open another can of worms, but what's the opinion
> of non-Linux ports maintainers on default init?
>
> Or maybe I should turn it another way:
>
> If we have working OpenRC on kFreeBSD and GNU Hurd, can
On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
> On 02/18/2014 10:15 PM, Ondřej Surý wrote:
[...]
> > If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
> >
> > Depends: systemd | openrc
> >
> > if I want to get rid of non-declarative init scripts in my daemon
> > pac
On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
> Once I consider OpenRC ready for it, would it be ok to just replace
> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
> What is the opinion of other DDs? Is there anyone which would like to
> keep the old featur
On 02/18/2014 10:15 PM, Ondřej Surý wrote:
> Hi,
>
> I don't really want to open another can of worms, but what's the opinion
> of non-Linux ports maintainers on default init?
>
> Or maybe I should turn it another way:
>
> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
>
> Depend
92 matches
Mail list logo
