On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
Honestly, I think a better solution would be to provide a convenience
function library, independent of OpenRC.
On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
Honestly, I think a better solution would be
On Wed, 29 Jun 2011 02:07:52 -0400
Mike Frysinger vap...@gentoo.org wrote:
/etc/init.d/functions.sh has existed for the last decade, and was
long ago decided as the canonical public entry point for scripts
external to baselayout (as opposed to a path in /sbin/). it isnt
going anywhere, and
On Wed, Jun 29, 2011 at 02:12, Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger wrote:
On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
/etc/init.d/functions.sh has existed for the last decade, and was
long ago decided as the canonical public entry point for scripts
external to baselayout (as opposed to a path in
2011/6/28 Olivier Crête:
As long as we have Gentoo-style init scripts in the tree, we will need
these functions to be available. So yes, they should probably be in a
separate package from openrc itself to ease the transition to the bright
systemd future.
systemd is limited (acknowledged by
On Wed, 29 Jun 2011 02:36:05 -0400
Mike Frysinger vap...@gentoo.org wrote:
On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
/etc/init.d/functions.sh has existed for the last decade, and was
long ago decided as the canonical
On Wed, Jun 29, 2011 at 2:12 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote:
On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
On Wednesday, June 29,
On Wed, Jun 29, 2011 at 02:38, Ciaran McCreesh wrote:
On Wed, 29 Jun 2011 02:36:05 -0400 Mike Frysinger wrote:
On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
/etc/init.d/functions.sh has existed for the last decade, and was
probably not worth getting into
-mike
now that we have autotools.eclass to ease regenerating of autotools in
ebuilds and people have generally adopted this tree-wide, i'd like to
look at dropping autoconf, automake, and libtool from the system set.
i'll wait for the current stage-breaking issue to get sorted out (/dev
nodes in
On Wed, 29 Jun 2011 02:47:36 -0400
Mike Frysinger vap...@gentoo.org wrote:
Both. There's code in Paludis that duplicates a bunch of that stuff
simply because I wasn't sure what I could and couldn't rely upon.
the file should provide the classic e* output funcs that we've all
grown to love,
Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny:
As I said it already, we could start doing things simpler in the
current python.eclass and maybe that would attract some devs to help
out with it, as they find it more comfortable to work with.
I think it would be better to
On Wed, Jun 29, 2011 at 02:53, Ciaran McCreesh wrote:
On Wed, 29 Jun 2011 02:47:36 -0400 Mike Frysinger wrote:
Both. There's code in Paludis that duplicates a bunch of that stuff
simply because I wasn't sure what I could and couldn't rely upon.
the file should provide the classic e* output
On Wed, 29 Jun 2011, Mike Frysinger wrote:
/etc/init.d/functions.sh has existed for the last decade, and
was long ago decided as the canonical public entry point for
scripts external to baselayout (as opposed to a path in
/sbin/).
the file should provide the classic e* output funcs
On 06/29/11 03:07, Olivier Crête wrote:
Hi,
On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
The background is that /etc/init.d/functions.sh is a link to
/lib/rc/functions.sh, which is part of openrc.
Other init systems, like systemd, are coming along which completely
replace
On Wed, 29 Jun 2011 07:38:45 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Wed, 29 Jun 2011 02:36:05 -0400
Mike Frysinger vap...@gentoo.org wrote:
On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
El mié, 29-06-2011 a las 09:18 +0200, Andreas K. Huettel escribió:
Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny:
As I said it already, we could start doing things simpler in the
current python.eclass and maybe that would attract some devs to help
out with it, as they find
On 06/29/2011 05:08 AM, Patrick Lauer wrote:
On 06/29/11 03:07, Olivier Crête wrote:
Hi,
On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
The background is that /etc/init.d/functions.sh is a link to
/lib/rc/functions.sh, which is part of openrc.
Other init systems, like systemd, are
On Wed, Jun 29, 2011 at 5:08 AM, Patrick Lauer patr...@gentoo.org wrote:
We tolerate the systemd madness as long as it doesn't interfere with
other things.
I'd say that welcome is a better word than tolerate - after all,
Gentoo is about choice. :)
Still, I do agree that we should avoid
В Срд, 29/06/2011 в 07:53 +0100, Ciaran McCreesh пишет:
On Wed, 29 Jun 2011 02:47:36 -0400
Mike Frysinger vap...@gentoo.org wrote:
Both. There's code in Paludis that duplicates a bunch of that stuff
simply because I wasn't sure what I could and couldn't rely upon.
the file should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29-06-2011 06:53, Mike Frysinger wrote:
now that we have autotools.eclass to ease regenerating of autotools in
ebuilds and people have generally adopted this tree-wide, i'd like to
look at dropping autoconf, automake, and libtool from the
2011-06-29 02:33:34 Jesus Rivero (Neurogeek) napisał(a):
With python-updater, well, some time ago Ali Polatel implemented some
approaches to get rid of python-updater, by exporting some variable in
ebuilds that needed to be rebuilt when new python versions were
installed. I dont recall what
2011-06-26 13:48:02 Thomas Sachau napisał(a):
In case of slotted dependencies (like python, ruby or php), this would also
allow the user to define
per package, if he wants support for one or more slots of e.g. python.
You can set USE_PYTHON in /etc/portage/env/${CATEGORY}/${PN} or
2011-06-27 22:57:05 Thomas Sachau napisał(a):
Dirkjan Ochtman wrote:
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen grob...@gentoo.org wrote:
On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
It would be nice when a similar technique could be implemented only
once, in a consistent way.
gentoo-x86/licenses contains the following licenses:
PSF-2.2
PSF-2.3
PSF-2.4
PYTHON
PSF-2.2, PSF-2.3 and PSF-2.4 contain some versions of Python Software
Foundation License Version 2,
which differ only in versions of Python, copyright years etc. They also contain
some history of
Python
On Wed, 2011-06-29 at 11:08 +0200, Patrick Lauer wrote:
On 06/29/11 03:07, Olivier Crête wrote:
Hi,
On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
The background is that /etc/init.d/functions.sh is a link to
/lib/rc/functions.sh, which is part of openrc.
Other init
On 06/29/11 17:14, Olivier Crête wrote:
On Wed, 2011-06-29 at 11:08 +0200, Patrick Lauer wrote:
On 06/29/11 03:07, Olivier Crête wrote:
Hi,
On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
The background is that /etc/init.d/functions.sh is a link to
/lib/rc/functions.sh, which is
On Wed, 29 Jun 2011 17:31:43 +0200, Patrick Lauer wrote:
On 06/29/11 17:14, Olivier Crête wrote:
Stop polluting the thread with $init vs $init2, please.
-Jeremy
On Wed, 29 Jun 2011 11:14:22 -0400
Olivier Crête tes...@gentoo.org wrote:
And you also underestimate the amount of momentum that Lennart has
managed to amass behind systemd. I expect that much sooner than you
think, we won't have a choice but to switch to systemd as many core
components will
On Wed, Jun 29, 2011 at 03:38, Ulrich Mueller wrote:
On Wed, 29 Jun 2011, Mike Frysinger wrote:
/etc/init.d/functions.sh has existed for the last decade, and
was long ago decided as the canonical public entry point for
scripts external to baselayout (as opposed to a path in
/sbin/).
the
On Wed, Jun 29, 2011 at 06:05, Michał Górny wrote:
I'm not sure if it is a good idea to source a script mangling PATH
there.
the mangling makes sure the system paths are present and come first.
it doesnt remove any elements.
it probably could be redone to only prepend elements, but i'm not
On Wed, Jun 29, 2011 at 12:56:32PM -0400, Mike Frysinger wrote:
On Wed, Jun 29, 2011 at 10:57, William Hubbs wrote:
The third option is for openrc to not install the
symbolic link at /etc/init.d/functions.sh since the code is actually at
/lib/rc/functions.sh or /libexec/rc/functions.sh on
On Wed, Jun 29, 2011 at 9:16 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Wed, 29 Jun 2011 11:14:22 -0400
Olivier Crête tes...@gentoo.org wrote:
And you also underestimate the amount of momentum that Lennart has
managed to amass behind systemd. I expect that much sooner than
2011/6/29 Olivier Crête tes...@gentoo.org:
systemd is where the innovation is today and we, Gentoo,
should get on board or be left behind.
Certainly agree that systemd is innovative.
I think this whole thing is becoming a bit moot. The openrc
maintainer is already planning to add use flags to
On Wed, 29 Jun 2011 16:46:13 -0500
William Hubbs willi...@gentoo.org wrote:
On Wed, Jun 29, 2011 at 12:56:32PM -0400, Mike Frysinger wrote:
On Wed, Jun 29, 2011 at 10:57, William Hubbs wrote:
The third option is for openrc to not install the
symbolic link at /etc/init.d/functions.sh
On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote:
Ok, the option that I'm looking at now is to set up openrc so that the
init scripts are optional and whether or not they are installed is
controlled by a use flag which I will
37 matches
Mail list logo
