On 11/06/2013 10:14 PM, Thorsten Glaser wrote:
> but the propo-
> nents of systemd, upstart *and* openrc (to a lesser amount)
> alike *all* want to *not* keep supporting init scripts).
Just FYI, here's my view...
I'd love to have a patch in OpenRC so that we'd have something like
/etc/init.d.open
On 11/06/2013 09:33 PM, Gergely Nagy wrote:
> Switching to systemd/upstart/OpenRC will not mean the rest will be
> dropped.
Whatever the decision we take, I really wish we deprecate sysv-rc in the
favor of OpenRC. It would really make sense, even if systemd or Upstart
becomes the default.
Also, I
On 11/06/2013 07:00 AM, Paul Tagliamonte wrote:
> If you want to hold your own system back, there's nothing stoping you
> (and your rights granted by f/oss software allow you to do so).
And there's nothing stopping you from contributing to OpenRC either, if
you feel, like me, that it's free of big
On 12/25/2013 05:50 PM, John Paul Adrian Glaubitz wrote:
> On 12/25/2013 08:46 AM, Thomas Goirand wrote:
>>> And overriding the *entire* service file seems excessive if you wish to
>>> override just one line of the package's service file.
>>
>> And also, systemd would be the only package behaving t
On 12/25/2013 08:46 AM, Thomas Goirand wrote:
>> And overriding the *entire* service file seems excessive if you wish to
>> override just one line of the package's service file.
>
> And also, systemd would be the only package behaving this way, which is
> counter-intuitive for our users. I'd even
On 10/31/2013 09:47 PM, Steven Chamberlain wrote:
> On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
>> two places where to place systemd service files. One is located
>> below /usr/lib/systemd which is the directory where service files
>> provided by the package are placed, and
On Tue, Dec 24, 2013 at 05:47:05PM +0100, Tzafrir Cohen wrote:
> On Tue, Dec 24, 2013 at 02:19:36AM +0100, Philipp Kern wrote:
> > On 2013-12-23 13:15, Sergey B Kirpichev wrote:
>
> [a potentially badly-phrased question]
>
> > ...I don't think many continue to read your rant and take your
> > "fe
On Tue, Dec 24, 2013 at 02:19:36AM +0100, Philipp Kern wrote:
> On 2013-12-23 13:15, Sergey B Kirpichev wrote:
[a potentially badly-phrased question]
> ...I don't think many continue to read your rant and take your
> "feedback" seriously. Apart from those who already resonate with
> your opinion.
On 2013-12-23 13:15, Sergey B Kirpichev wrote:
You don’t want anything like these in your local init service. For
such
tests you have Nagios, Icinga or similiar daemons. And they can do
much
deeper checks, e.g. can you login into your webservice because your
database backend on a different serv
>> You don’t want anything like these in your local init service. For such
>> tests you have Nagios, Icinga or similiar daemons. And they can do much
>> deeper checks, e.g. can you login into your webservice because your
>> database backend on a different server is available.
>
> Once your monit
On Mon, Nov 11, 2013 at 10:24:36PM +0100, Olav Vitters wrote:
> On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote:
> > >Or a private tmp?
> >
> > I shudder at the mere thought of allowing a dæmon to unshare
> > its /tmp from the rest of the system, because of the maintenance
> > nigh
On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote:
> Matthias Urlichs dixit:
>
> >A systemd service file is five lines.
>
> Someone has shown that this works with sysvinit as well,
> if you use #!/path/to/some-helper as shebang.
Nice theory, but in practice it is a mess. That peopl
Matthias Urlichs dixit:
>A systemd service file is five lines.
Someone has shown that this works with sysvinit as well,
if you use #!/path/to/some-helper as shebang.
>Want more features in your init script? Like, say, a reliable way to
>figure out if any parts of your server are still running af
Le dimanche 10 novembre 2013 à 20:23 +0100, Stephan Seitz a écrit :
> You don’t want anything like these in your local init service. For such
> tests you have Nagios, Icinga or similiar daemons. And they can do much
> deeper checks, e.g. can you login into your webservice because your
> database
On Sun, Nov 10, 2013 at 11:25:32AM +, Matthias Urlichs wrote:
Want more features in your init script? Like, say, a reliable way to
figure out if any parts of your server are still running after it
crashed? Or a way to determine that it has started up correctly?
You don’t want anything like
On 11/01/2013 02:00 AM, Kevin Chadwick wrote:
> previously on this list Wouter Verhelst contributed:
>
>>> By absense of documentation, are you referring to the almost 10% of the
>>> source base that are comments or the 15% that is DocBook XML based
>>> documentation? (Almost 14kLOC and almost 36
Marko Randjelovic eunet.rs> writes:
> > >
> > That's exactly how I feel when I want to create a small daemon using a
> > SystemV init script. I feel like building an airplane from scratch while
> > I would just use a bike.
>
Sure, systemd is "bloated". Just like the kernel is bloated, I presume
❦ 6 novembre 2013 17:43 CET, Marko Randjelovic :
>> That's exactly how I feel when I want to create a small daemon using a
>> SystemV init script. I feel like building an airplane from scratch while
>> I would just use a bike.
>
> Use /etc/init.d/skeleton and you'll see it's very simple.
The
❦ 6 novembre 2013 18:53 CET, Florian Weimer :
>>> Curiously, a lot of system administrators do not do this correctly
>>> using sysvinit, causing system daemons to start unexpectedly after
>>> installing package updates.
>>
>> What *is* the correct way, anyway?
>
> Renaming the S symlinks to K s
On Wed, Nov 06, 2013 at 06:53:40PM +0100, Florian Weimer wrote:
[...]
Again, good points, but ones we've discussed. Perhaps we should end this
thread?
Fondly,
Paul
--
.''`. Paul Tagliamonte
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`
* Thorsten Glaser:
> On Thu, 31 Oct 2013, Florian Weimer wrote:
>
>> Curiously, a lot of system administrators do not do this correctly
>> using sysvinit, causing system daemons to start unexpectedly after
>> installing package updates.
>
> What *is* the correct way, anyway?
Renaming the S symlin
This discussion isn't really furthering the development of Debian
and the init system question is already with the technical committee
so can we please take such discussions off-list, if one is determined
to continue them.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Wed, 06 Nov 2013 14:04:53 +0100
Adrien CLERC wrote:
> >>> And SysVInit just works well and it is simply enough. It has much less
> >>> dependencies than systemd. Do not make unneeded weight on people to learn
> >>> systemd in addition to shell scripts, if systemd is powerful that also
> >>>
On Wed, Nov 06, 2013 at 03:14:14PM +0100, Thorsten Glaser wrote:
[snip]
Some good points made all around, more for the ctte to consider. As
Jonathan says, it's in ctte's hands now, let's agree to disagree and let
the poor souls on the commitee do their job
Cheers,
Paul
--
.''`. Paul Tagliam
On Wed, 6 Nov 2013, Gergely Nagy wrote:
> Please no. That's a maintenance nightmare. I'm fine with one on
> GNU/Linux, another everywhere else (but I'll treat everything else as
> secondary), but supporting all of them, everywhere they're available, is
> madness.
And:
> Freedom of choice remains
On Wed, Nov 06, 2013 at 02:33:36PM +0100, Gergely Nagy wrote:
> Please no. That's a maintenance nightmare. I'm fine with one on
> GNU/Linux, another everywhere else (but I'll treat everything else as
> secondary), but supporting all of them, everywhere they're available, is
> madness.
This is now
Thorsten Glaser writes:
> On Tue, 5 Nov 2013, Paul Tagliamonte wrote:
>
>> > First of all, I do not agree Debian community is hurt because of
>> > split about init system,
>>
>> I disagree strongly. Please read through every flame thread over the
>> last 4 years and try to say this with a straig
And SysVInit just works well and it is simply enough. It has much less
dependencies than systemd. Do not make unneeded weight on people to learn
systemd in addition to shell scripts, if systemd is powerful that also means
there is a lot to learn. I really doubt non-standards task can be solved
On Tue, 5 Nov 2013, Paul Tagliamonte wrote:
> > First of all, I do not agree Debian community is hurt because of
> > split about init system,
>
> I disagree strongly. Please read through every flame thread over the
> last 4 years and try to say this with a straight face.
That’s why I say let’s j
On Tue, 5 Nov 2013 18:00:09 -0500
Paul Tagliamonte wrote:
> What? Sorry, what? Are you disagreeing with yourself? If it's so
> important to a UNIX system, why do you say it's not technical ...
I said it's not *only* technical.
> > Big companies all over and over again show they care much more
On Tue, Nov 05, 2013 at 11:43:16PM +0100, Marko Randjelovic wrote:
> On Sat, 26 Oct 2013 11:07:36 +0200
> Lucas Nussbaum wrote:
>
> > I think that it would be a failure of the Debian project if we had to have
> > a GR
> > about such a technical decision. I think that we need to trust that the
>
On Sat, 26 Oct 2013 11:07:36 +0200
Lucas Nussbaum wrote:
> I think that it would be a failure of the Debian project if we had to have a
> GR
> about such a technical decision. I think that we need to trust that the
> Technical Committee will make the right decision. A GR about this will likely
>
previously on this list Ben Hutchings contributed:
> > > In other words, Canonical gets the right to take a free software
> > > contribution and make it proprietary. The contributors gets to own the
> > > software, and can continue releasing it as free software, but can't
> > > prevent Canonical f
On Thu, Oct 31, 2013 at 11:40:20PM +0100, gregor herrmann wrote:
[...]
> > In other words, Canonical gets the right to take a free software
> > contribution and make it proprietary. The contributors gets to own the
> > software, and can continue releasing it as free software, but can't
> > prevent
On Thu, 31 Oct 2013 18:10:31 +, Lars Wirzenius wrote:
> On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote:
> > Actually, contributing to Upstart does not require copyright assignment (as
> > for example, would contributing to an FSF-owned GNU project). Instead, it
> > requires a Co
On Thu, Oct 31, 2013 at 07:20:12AM -0400, Theodore Ts'o wrote:
> On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
> > I'm surprised by this comment. Very little policy is actually encoded in
> > upstart's C code; in fact, the only policy I can think of offhand that is is
> > some ba
--text follows this line--
Theodore Ts'o writes ("Re: Bug#727708: tech-ctte: Decide which init system to
default to in Debian."):
> On a different subject, which I don't think has been raised so far ---
> has the Debian maintinares for the upstart package made any com
On Oct 31, 2013, at 06:10 PM, Lars Wirzenius wrote:
>Quoting from the PDF linked from that page ("Canonical Individual
>Contributor License Agreement" for individual contributors):
>
>Based on the grant of rights in Sections 2.1 and 2.2, if We
>include Your Contribution in a Material, We m
previously on this list Wouter Verhelst contributed:
> > By absense of documentation, are you referring to the almost 10% of the
> > source base that are comments or the 15% that is DocBook XML based
> > documentation? (Almost 14kLOC and almost 36kLOX, respectively.)
>
> That particular commen
previously on this list Theodore Ts'o contributed:
> So hopefully that is something the technical committee will take into
> account --- how well things are documented, both in terms of a
> comprehensive reference manual, and a tutorial that helps people with
> common things that system administra
On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote:
> Actually, contributing to Upstart does not require copyright assignment (as
> for example, would contributing to an FSF-owned GNU project). Instead, it
> requires a Contributor License Agreement be signed:
>
> http://www.canonical.co
On Thu, Oct 31, 2013 at 03:59:25PM +, Jonathan Dowland wrote:
> On Thu, Oct 31, 2013 at 02:04:24PM +, Steven Chamberlain wrote:
> > > [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
> > This doesn't appear to be a bug in Upstart.
> Strictly, no, but there was a surprisin
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> > I suspect you and I have a root disagreement over the utility of exposing
> > some of those degrees of freedom to every init script author, but if you
> > have some mor
On 10/31/2013 03:04 PM, Steven Chamberlain wrote:
> On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
>> messed up custom code may end up rendering your whole system unusable
>> if you are smart enough to mess up an rm command. Just have a look
>> at this wonderful bug in upstart
On Thu, Oct 31, 2013 at 02:04:24PM +, Steven Chamberlain wrote:
> > [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
>
> This doesn't appear to be a bug in Upstart.
Strictly, no, but there was a surprising amount of resistance to adding
some boilerplate to that script to some
On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote:
> The difference of course is that with the CLA, you continue "to own the
> copyright in the contribution, with full rights to re-use, re-distribute, and
> continue modifying the contributed code", but it allows Canonical to use your
> c
On Oct 31, 2013, at 07:45 AM, Theodore Ts'o wrote:
>On a different subject, which I don't think has been raised so far ---
>has the Debian maintinares for the upstart package made any comments
>about bug fixes or code contributions from Debian Developers who are
>personally opposed to being forced
]] Theodore Ts'o
> I don't think copyright assignment is a concern which afflicts
> Systemd, although there is a related concern which is that the
> upstream systemd developers appear to have a very strong point of
> view, and if there is some change which is needed for Debian or
> Debian's users
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
> messed up custom code may end up rendering your whole system unusable
> if you are smart enough to mess up an rm command. Just have a look
> at this wonderful bug in upstart [1].
> [1] https://bugs.launchpad.net/ubuntu/+source/u
]] Theodore Ts'o
> The upstart documentation, from my brief examination, seems to be much
> more approachable for someone who is starting from ground zero.
Have you read the «The systemd for Administrators Blog Series» linked to
from http://www.freedesktop.org/wiki/Software/systemd/ ?
--
Tolle
On Thu, Oct 31, 2013 at 01:47:37PM +, Steven Chamberlain wrote:
> And overriding the *entire* service file seems excessive if you wish to
> override just one line of the package's service file.
You add a file /etc/systemd/system/xxx.service.d/yyy.conf with the following
contents:
[Service]
Se
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
> two places where to place systemd service files. One is located
> below /usr/lib/systemd which is the directory where service files
> provided by the package are placed, and one is /etc/systemd where
> your own, custom service fi
On 31/10/13 13:06, Thorsten Glaser wrote:
>> My understanding is that something like `update-rc.d $service disable`
>
> … isn’t that overwritten by the update-rc.d commands in the
> maintainer scripts (postinst) when the package is upgraded?
Not in the sysv-rc implementation, at least. `update-rc
* Thorsten Glaser [Thu Oct 31, 2013 at 01:27:12PM +0100]:
> On Thu, 31 Oct 2013, Florian Weimer wrote:
> > Curiously, a lot of system administrators do not do this correctly
> > using sysvinit, causing system daemons to start unexpectedly after
> > installing package updates.
> What *is* the corr
On Thu, 31 Oct 2013, Simon McVittie wrote:
> file-rc ships its own update-rc.d implementation (at least, according to
> the package description it does) which hopefully has the enable/disable
> subcommands.
It does, but…
> My understanding is that something like `update-rc.d $service disable`
…
On 31/10/13 12:27, Thorsten Glaser wrote:
> On Thu, 31 Oct 2013, Florian Weimer wrote:
>
>> Curiously, a lot of system administrators do not do this correctly
>> using sysvinit, causing system daemons to start unexpectedly after
>> installing package updates.
>
> What *is* the correct way, anyway
Hi Thorsten,
On Wed, Oct 30, 2013 at 04:05:48PM +, Thorsten Glaser wrote:
> * Write scripts for one system and generate the other from it
> or even
> * Write ???Debian init declaration??? and let something take care
> of generating an initscript and whatever the other systems
> use out of
On Thu, 31 Oct 2013, Florian Weimer wrote:
> Curiously, a lot of system administrators do not do this correctly
> using sysvinit, causing system daemons to start unexpectedly after
> installing package updates.
What *is* the correct way, anyway?
My coworkers tell me to delete the symlinks in /et
Hi,
On 31/10/13 12:45, Theodore Ts'o wrote:
> On a different subject, which I don't think has been raised so far ---
> has the Debian maintinares for the upstart package made any comments
> about bug fixes or code contributions from Debian Developers who are
> personally opposed to being forced to
On a different subject, which I don't think has been raised so far ---
has the Debian maintinares for the upstart package made any comments
about bug fixes or code contributions from Debian Developers who are
personally opposed to being forced to sign copyright assignment
agreements, or for whom th
On Wed, Oct 30, 2013 at 10:52:15PM -0700, Russ Allbery wrote:
> >> You can do quite a bit with the hooks that are part of the specification
> >> of both types of files. For example, logic that you may add to control
> >> whether the service should start at all can be implemented by adding a
> >> p
On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
> I'm surprised by this comment. Very little policy is actually encoded in
> upstart's C code; in fact, the only policy I can think of offhand that is is
> some basic stuff around filesystems, which, aside from some must-have kernel
>
* Theodore Ts'o:
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
Curiously, a lot of system administrators do not do this correctly
usin
Op 30-10-13 16:58, Tollef Fog Heen schreef:
> ]] Wouter Verhelst
>
>> Yes, absense of documentation is common on Unix and Linux systems; but
>> no, I do not think that this is okay, or that we should in any way
>> encourage that sort of thing.
>
> By absense of documentation, are you referring t
Op 31-10-13 02:50, Theodore Ts'o schreef:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of exposing
>> some of those degrees of freedom to every init script author, but if you
>> have some more specific examples of p
On Wed, Oct 30, 2013 at 08:41:10PM -0400, Theodore Ts'o wrote:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> > Well, I've said this before, but I think it's worth reiterating. Either
> > upstart or systemd configurations are *radically better* than init scripts
> > on basically
On Wed, 30 Oct 2013 21:50:53 -0400, Theodore Ts'o wrote:
>
> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.
>
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service
On 10/30/2013 11:58 PM, Tollef Fog Heen wrote:
> ]] Wouter Verhelst
>
>> Yes, absense of documentation is common on Unix and Linux systems; but
>> no, I do not think that this is okay, or that we should in any way
>> encourage that sort of thing.
>
> By absense of documentation, are you referrin
Tollef Fog Heen writes:
> ]] Russ Allbery
> (Cleaned up the Cc line somewhat)
>> You can do quite a bit with the hooks that are part of the specification
>> of both types of files. For example, logic that you may add to control
>> whether the service should start at all can be implemented by a
]] Russ Allbery
(Cleaned up the Cc line somewhat)
> You can do quite a bit with the hooks that are part of the specification
> of both types of files. For example, logic that you may add to control
> whether the service should start at all can be implemented by adding a
> pre-start stanza to th
On 10/31/2013 02:50 AM, Theodore Ts'o wrote:
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> > I suspect you and I have a root disagreement over the utility of exposing
> > some of those degrees of freedom to every init script author, but if you
> > have some mor
Theodore Ts'o writes:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of
>> exposing some of those degrees of freedom to every init script author,
>> but if you have some more specific examples of policy that you wan
On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> I suspect you and I have a root disagreement over the utility of exposing
> some of those degrees of freedom to every init script author, but if you
> have some more specific examples of policy that you wanted to change but
> couldn't,
On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> Well, I've said this before, but I think it's worth reiterating. Either
> upstart or systemd configurations are *radically better* than init scripts
> on basically every axis. They're more robust, more maintainable, easier
> for the
Theodore Ts'o writes:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
>> Well, I've said this before, but I think it's worth reiterating.
>> Either upstart or systemd configurations are *radically better* than
>> init scripts on basically every axis. They're more robust, more
>>
previously on this list Russ Allbery contributed:
> > Well I meant that they would be used by systemd and ignored likely
> > noisily by default by others. However this really should be the job of
> > the service in any case as depending on a third party service for
> > security that isn't extra su
Kevin Chadwick writes:
> Well I meant that they would be used by systemd and ignored likely
> noisily by default by others. However this really should be the job of
> the service in any case as depending on a third party service for
> security that isn't extra such as potentially PrivateTmp that
previously on this list Jonathan Dowland contributed:
> > Couldn't they just be ignored not to mention already having existing or
> > far more functional and robust *options* that work with any init system.
>
> A cursory glance at the example above…
>
> > > PrivateTmp=yes
> > > InaccessibleDir
On Wed, 30 Oct 2013 20:39:32 + Jonathan Dowland wrote:
> [...] Debian without non-Linux ports prior to February
> 2011, [...]
That's only when a non-Linux Debian port (GNU/kFreeBSD) first became a
_release architecture_; it existed as a port since May 2003. Hurd has
been an official unstable
On Wed, Oct 30, 2013 at 07:25:55PM +, Kevin Chadwick wrote:
> Couldn't they just be ignored not to mention already having existing or
> far more functional and robust *options* that work with any init system.
A cursory glance at the example above…
> > PrivateTmp=yes
> > InaccessibleDirectorie
On Wed, Oct 30, 2013 at 08:59:00PM +0400, Игорь Пашев wrote:
> Debian is not Debian without non-Linux ports.
You are entitled to your opinion, which is what this is. Debian
certainly was Debian without non-Linux ports prior to February
2011, and some are of the opinion that it should be again in
f
previously on this list Helmut Grohne contributed:
> Most participants in this thread appear to agree that the sysvinit
> *interface* for services (shell scripts) is suboptimal.
Not so sure, I have various thoughts on this and even the reasons that
it is considered sub optimal but think some like
previously on this list Zbigniew Jędrzejewski-Szmek contributed:
> Hi Helmut,
> "exec" vs. "ExecStart=" and "export" vs. "Environment=" is easy.
> Anyone can whip up a sed script to convert between those. The question
> is how to deal with more advanced options. Let's say that I have a
> systemd u
On Wed, Oct 30, 2013 at 04:29:24PM +0100, Wouter Verhelst wrote:
> While I agree with your point, it's pretty difficult to reimplement the
> "interesting" parts of systemd in other implementations of pid1 if
> whoever wrote the "interesting" parts does not document it, does not say
> what it's supp
2013/10/30 Helmut Grohne :
> What is going to happen with non-Linux ports?
Debian is not Debian without non-Linux ports.
As for me, I think it is not very hard to maintain diffrent init
systems for different kernels.
Especially if Debian GNU/Linux get rid of sysvinit: writing systemd or upstrart
On Wed, 30 Oct 2013 16:05:48 +, Thorsten Glaser wrote:
> * Write scripts for one system and generate the other from it
> or even
> * Write “Debian init declaration” and let something take care
> of generating an initscript and whatever the other systems
> use out of it
Perhaps an existin
Steven Chamberlain dixit:
[…]
>substitute Upstart here if you prefer), each package's maintainer could:
[…]
* Write scripts for one system and generate the other from it
or even
* Write “Debian init declaration” and let something take care
of generating an initscript and whatever the other syst
]] Wouter Verhelst
> Yes, absense of documentation is common on Unix and Linux systems; but
> no, I do not think that this is okay, or that we should in any way
> encourage that sort of thing.
By absense of documentation, are you referring to the almost 10% of the
source base that are comments o
On Wed, 30 Oct 2013 15:10:16 +0100 Helmut Grohne wrote:
> Furthering this thought leads to turning non-Linux ports
> into derivatives as presented by others in this thread.
If packages are no longer required to provide SysV init scripts,
producing a non-Linux Debian derivative would at least entai
Op 30-10-13 00:16, Russ Allbery schreef:
> Carlos Alberto Lopez Perez writes:
>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
>
>>> For those who haven't seen it, Lennart has posted some of his comments
>>> about all this on G+:
>>> https://plus.google.com/u/0/115547683951727699051/posts/8R
On Wed, Oct 30, 2013 at 03:10:16PM +0100, Helmut Grohne wrote:
> The interfaces of all init systems (except sysvinit, but are we really
> considering that one?) still are somewhat in flux, so this is the point
> where we can still influence and shape them.
>
>
> Imagine a world where upstart and
Hi Steve,
On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
> On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> > Having read the parts of the ctte bug, it feels odd to preclude the
> > option of supporting multiple init systems from discussion or
> > consideration. If
on Tue, 29 Oct 2013 15:08:01 -0700 Russ Allbery wrote:
> However, I, as a packager, want to stop writing and maintaining SysV init
> scripts because they're awful.
I didn't really expect this. I'd assumed until now that most
maintainers would be concerned that existing init scripts don't work
pro
Hi,
Le mardi, 29 octobre 2013 15.08:01 Russ Allbery a écrit :
> However, making all package maintainers continue to go through the
> pain of maintaining SysV init scripts to support Hurd and kFreeBSD
> doesn't strike me as a good outcome.
It does for me.
First we're not talking about _all_ packa
Op 29-10-13 09:26, Steve Langasek schreef:
> I see no reason that, if upstart were chosen as the default, porters could
> not use it for our non-Linux ports as well.
With some work, sure.
> This is a much better outcome
> across our distribution as a whole than to require developers to continue
>
On 29/10/13 23:51, Svante Signell wrote:
> On Tue, 2013-10-29 at 00:51 -0700, Steve Langasek wrote:
>
>>> (Also, do remember that any decisive outcome other than “support
>>> multiple ones including systemd” and “systemd-only” will need to
>>> lead to the removal of GNOME from Debian.
>>
>> Absolu
Russ,
It seems we don't have at all the same reading of Patrick post. Note
that what's below is my comments on your comments about Patrick's
comments, and do not represent my view (which I do not wish to express
it more at this point).
On 10/30/2013 07:16 AM, Russ Allbery wrote:
> the core conten
On 10/29/2013 09:34 AM, Steven Chamberlain wrote:
> Hi,
>
> On Sun, 27 Oct 2013 02:47:56 +0800 Thomas Goirand wrote:
>> Note that OpenRC already works on some (non-Debian) BSD platforms, and
>> that it should be trivial to have it to build on kFreeBSD and Hurd,
>
> And so I came up with the attac
On 29/10/13 01:34, Steven Chamberlain wrote:
> Actually quite amazing how painless that was, though I most certainly
> don't expect it to be functional yet.
I have tested it now. It's actually running and doing 'something'! And
it is colourful.
I'm testing it inside of a BSD jail currently. Th
1 - 100 of 147 matches
Mail list logo
