[gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

Patch to avoid duplicating this code to every ebuild.

The second attachment is an example use case for the function.

Soon as this is in, I'll start mass converting the tree for this...

- Samuli

[-- Attachment #2: systemd.eclass.patch --]
[-- Type: text/x-patch, Size: 1146 bytes --]

--- systemd.eclass	2012-08-06 12:49:20.532528219 +0300
+++ /tmp/systemd.eclass	2012-08-06 12:57:28.333542735 +0300
@@ -25,6 +25,8 @@
 # }
 # @CODE
 
+inherit toolchain-funcs
+
 case ${EAPI:-0} in
 	0|1|2|3|4) ;;
 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
@@ -34,6 +36,31 @@
 DEPEND="!<sys-apps/systemd-29-r4
 	!=sys-apps/systemd-37-r1"
 
+# @FUNCTION: _systemd_get_udevdir
+# @INTERNAL
+# @DESCRIPTION:
+# Get unprefixed udevdir.
+_systemd_get_udevdir() {
+	if $($(tc-getPKG_CONFIG) --exists udev); then
+		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
+	else
+		echo -n /lib/udev
+	fi
+}
+
+# @FUNCTION: systemd_get_udevdir
+# @DESCRIPTION:
+# Output the path for the udev directory (not including ${D}).
+# This function always succeeds, even if udev is not installed.
+# Dependencies need to include sys-fs/udev or otherwise
+# the fallback return value is /lib/udev.
+systemd_get_udevdir() {
+	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+	debug-print-function ${FUNCNAME} "${@}"
+
+	echo -n "${EPREFIX}$(_systemd_get_udevdir)"
+}
+
 # @FUNCTION: _systemd_get_unitdir
 # @INTERNAL
 # @DESCRIPTION:

[-- Attachment #3: usb_modeswitch-1.2.3_p20120531-r2.ebuild.patch --]
[-- Type: text/x-patch, Size: 965 bytes --]

--- usb_modeswitch-1.2.3_p20120531-r2.ebuild	2012-08-06 12:59:07.308545675 +0300
+++ /tmp/usb_modeswitch-1.2.3_p20120531-r2.ebuild	2012-08-06 12:46:17.556522775 +0300
@@ -3,7 +3,7 @@
 # $Header: /var/cvsroot/gentoo-x86/sys-apps/usb_modeswitch/usb_modeswitch-1.2.3_p20120531-r2.ebuild,v 1.2 2012/08/06 08:22:44 ssuominen Exp $
 
 EAPI=4
-inherit linux-info toolchain-funcs
+inherit linux-info toolchain-funcs systemd
 
 MY_PN=${PN/_/-}
 MY_P=${MY_PN}-${PV/_p*}
@@ -42,7 +42,7 @@
 src_install() {
 	emake \
 		DESTDIR="${D}" \
-		UDEVDIR="${D}/$($(tc-getPKG_CONFIG) --variable=udevdir udev)" \
+		UDEVDIR="${D}/$(systemd_get_udevdir)" \
 		install
 
 	dodoc ChangeLog README
@@ -50,7 +50,7 @@
 	pushd ../${MY_PN}-data-${DATA_VER} >/dev/null
 	emake \
 		DESTDIR="${D}" \
-		RULESDIR="${D}/$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d" \
+		RULESDIR="${D}/$(systemd_get_udevdir)/rules.d" \
 		files-install db-install
 	docinto data
 	dodoc ChangeLog README

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]

Ok, a few comments from me.

On Mon, 06 Aug 2012 13:00:08 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> --- systemd.eclass	2012-08-06 12:49:20.532528219 +0300
> +++ /tmp/systemd.eclass	2012-08-06 12:57:28.333542735 +0300

First of all, I'm not really convinced systemd.eclass is a good place
for this.

The main reason for introducing a separate systemd.eclass was to have
a single place to control installing systemd unit files. The rule is
quite simple here: you install systemd unit files, you inherit
the eclass.

Most importantly, this allows us to easily find out which packages
install such files and perform global operations on them. For example,
if a particular user had systemd locations in INSTALL_MASK and changed
his mind, he can easily update his system by rebuilding all packages
inheriting systemd.eclass.

If all packages installing udev rules start inheriting it, the above
will no longer be correct. Also, the opposite way -- rebuilding
packages installing udev rules -- won't be that easy.

That's not my call but I believe that putting those functions in
separate udev.eclass could be the best course of action, for the reason
stated above -- we can easily find out what installs them, and rebuild
it all at once.

> @@ -25,6 +25,8 @@
>  # }
>  # @CODE
>  
> +inherit toolchain-funcs
> +
>  case ${EAPI:-0} in
>  	0|1|2|3|4) ;;
>  	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> established." @@ -34,6 +36,31 @@
>  DEPEND="!<sys-apps/systemd-29-r4
>  	!=sys-apps/systemd-37-r1"
>  
> +# @FUNCTION: _systemd_get_udevdir
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Get unprefixed udevdir.
> +_systemd_get_udevdir() {
> +	if $($(tc-getPKG_CONFIG) --exists udev); then
> +		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> udev)"

Secondly, I believe you shouldn't do such a thing *without* depending
on udev. Even though there is fallback here, there is another problem:
you are introducing a *potential inconsistency* between built packages,
depending on contents of udev.pc. Thus, I believe the package should
depend on the package providing it so that the dependency tree is
complete.

Also, I'm not so sure if this will work correctly for Prefix.

> +	else
> +		echo -n /lib/udev
> +	fi
> +}

And finally, I believe we shouldn't even be making the install location
variable. Right now, the Gentoo location for udev rules is /lib/udev,
and I believe William will agree with me on this. We hadn't decided on
moving them, and thus all udev and systemd versions in the tree *will*
support /lib/udev (I still need to commit patched systemd).

If we decide to move rules to /usr/lib/udev, I believe we will move
them all at once. And then all users will have to use a newer
(or patched) udev supporting the new location (or both). In order to
enforce that, the eclass would have to block old udev versions (like
the systemd.eclass blocks old systemd versions).

Making the install location dynamic is just asking for trouble.
Consider the following: user installs new udev, rebuilds package, then
downgrades udev. Package rules no longer work. That's what we would
like to avoid.

> +
> +# @FUNCTION: systemd_get_udevdir
> +# @DESCRIPTION:
> +# Output the path for the udev directory (not including ${D}).
> +# This function always succeeds, even if udev is not installed.
> +# Dependencies need to include sys-fs/udev or otherwise
> +# the fallback return value is /lib/udev.
> +systemd_get_udevdir() {
> +	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> +	debug-print-function ${FUNCNAME} "${@}"
> +
> +	echo -n "${EPREFIX}$(_systemd_get_udevdir)"
> +}
> +
>  # @FUNCTION: _systemd_get_unitdir
>  # @INTERNAL
>  # @DESCRIPTION:

As a final note, please note that this is mostly my opinion as systemd
maintainer. I believe William has a final word on udev itself.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Samuli Suominen]

On 08/06/2012 01:20 PM, Michał Górny wrote:
> Ok, a few comments from me.
>
> On Mon, 06 Aug 2012 13:00:08 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> --- systemd.eclass	2012-08-06 12:49:20.532528219 +0300
>> +++ /tmp/systemd.eclass	2012-08-06 12:57:28.333542735 +0300
>
> First of all, I'm not really convinced systemd.eclass is a good place
> for this.
>
> The main reason for introducing a separate systemd.eclass was to have
> a single place to control installing systemd unit files. The rule is
> quite simple here: you install systemd unit files, you inherit
> the eclass.
>
> Most importantly, this allows us to easily find out which packages
> install such files and perform global operations on them. For example,
> if a particular user had systemd locations in INSTALL_MASK and changed
> his mind, he can easily update his system by rebuilding all packages
> inheriting systemd.eclass.
>
> If all packages installing udev rules start inheriting it, the above
> will no longer be correct. Also, the opposite way -- rebuilding
> packages installing udev rules -- won't be that easy.
>
> That's not my call but I believe that putting those functions in
> separate udev.eclass could be the best course of action, for the reason
> stated above -- we can easily find out what installs them, and rebuild
> it all at once.


OK, we can make it udev.eclass and then we can add the virtual/pkgconfig 
and sys-fs/udev dependency of it.


>
>> @@ -25,6 +25,8 @@
>>   # }
>>   # @CODE
>>
>> +inherit toolchain-funcs
>> +
>>   case ${EAPI:-0} in
>>   	0|1|2|3|4) ;;
>>   	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
>> established." @@ -34,6 +36,31 @@
>>   DEPEND="!<sys-apps/systemd-29-r4
>>   	!=sys-apps/systemd-37-r1"
>>
>> +# @FUNCTION: _systemd_get_udevdir
>> +# @INTERNAL
>> +# @DESCRIPTION:
>> +# Get unprefixed udevdir.
>> +_systemd_get_udevdir() {
>> +	if $($(tc-getPKG_CONFIG) --exists udev); then
>> +		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
>> udev)"
>
> Secondly, I believe you shouldn't do such a thing *without* depending
> on udev. Even though there is fallback here, there is another problem:
> you are introducing a *potential inconsistency* between built packages,
> depending on contents of udev.pc. Thus, I believe the package should
> depend on the package providing it so that the dependency tree is
> complete.

OK, I can agree with udev.eclass as I stated before already.

>
> Also, I'm not so sure if this will work correctly for Prefix.

I'm sure that is easily checked and we will get feedback quickly.

>
>> +	else
>> +		echo -n /lib/udev
>> +	fi
>> +}
>
> And finally, I believe we shouldn't even be making the install location
> variable.

It's the upstream way to determine the path and is used treewide by 
upstream configure scripts etc. for various packages already.

 > Right now, the Gentoo location for udev rules is /lib/udev,
> and I believe William will agree with me on this. We hadn't decided on
> moving them, and thus all udev and systemd versions in the tree *will*
> support /lib/udev (I still need to commit patched systemd).
>
> If we decide to move rules to /usr/lib/udev, I believe we will move
> them all at once. And then all users will have to use a newer
> (or patched) udev supporting the new location (or both). In order to
> enforce that, the eclass would have to block old udev versions (like
> the systemd.eclass blocks old systemd versions).

The udevdir is whatever udev.pc determines it to be, and currently in 
~arch it's set to /usr/lib/udev
Therefore the Gentoo udevdir is also /usr/lib/udev for ~arch

As in, packages in tree are using it already, independent of getting 
this helper function to tree or not.

>
> Making the install location dynamic is just asking for trouble.
> Consider the following: user installs new udev, rebuilds package, then
> downgrades udev. Package rules no longer work. That's what we would
> like to avoid.

Downgrading is never a good idea when you don't know what you are doing.

>
>> +
>> +# @FUNCTION: systemd_get_udevdir
>> +# @DESCRIPTION:
>> +# Output the path for the udev directory (not including ${D}).
>> +# This function always succeeds, even if udev is not installed.
>> +# Dependencies need to include sys-fs/udev or otherwise
>> +# the fallback return value is /lib/udev.
>> +systemd_get_udevdir() {
>> +	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
>> +	debug-print-function ${FUNCNAME} "${@}"
>> +
>> +	echo -n "${EPREFIX}$(_systemd_get_udevdir)"
>> +}
>> +
>>   # @FUNCTION: _systemd_get_unitdir
>>   # @INTERNAL
>>   # @DESCRIPTION:
>
> As a final note, please note that this is mostly my opinion as systemd
> maintainer. I believe William has a final word on udev itself.

Summarizing:

- Will call this udev.eclass and add the dependencies for udev and 
pkg-config

- Gentoo's udevdir is already set to /usr/lib/udev by 
 >=sys-fs/udev-187-r1 in Portage, and is widely queried by upstream 
configure scripts
We should leave it like it is now, and get this helper function ASAP in 
tree to get things consistent again

- Samuli

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote:
> > Also, I'm not so sure if this will work correctly for Prefix.
> 
> I'm sure that is easily checked and we will get feedback quickly.

I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is
more sensical not to pseudo-provide support for it.

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On 08/06/2012 01:42 PM, Fabian Groffen wrote:
> On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote:
>>> Also, I'm not so sure if this will work correctly for Prefix.
>>
>> I'm sure that is easily checked and we will get feedback quickly.
>
> I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is
> more sensical not to pseudo-provide support for it.
>

after thinking about this over:

rules files are often small and often get always installed, yet the 
package might be running just fine without udev, the installed rules 
files just don't get used

therefore adding sys-fs/udev dependency to the eclass is out of question 
and should be left for ebuilds

therefore pseudo-prefix support should be left in place too... right?

attaching latest based on mgorny's feedback...

[-- Attachment #2: udev.eclass --]
[-- Type: text/plain, Size: 1272 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: udev.eclass
# @MAINTAINER:
# udev-bugs@gentoo.org
# @BLURB: helper function to determine udevdir
# @DESCRIPTION:
# This eclass provides a function to get the default udev path.
# @EXAMPLE:
#
# @CODE
# inherit udev
#
# src_configure() {
#	econf --with-udevdir="$(udev_get_udevdir)"
# }
# @CODE

inherit toolchain-funcs

case ${EAPI:-0} in
	0|1|2|3|4) ;;
	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac

RDEPEND=""
DEPEND="virtual/pkgconfig"

# @FUNCTION: _udev_get_udevdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udevdir.
_udev_get_udevdir() {
	if $($(tc-getPKG_CONFIG) --exists udev); then
		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
	else
		echo -n /lib/udev
	fi
}

# @FUNCTION: udev_get_udevdir
# @DESCRIPTION:
# Output the path for the udev directory (not including ${D}).
# This function always succeeds, even if udev is not installed.
# The fallback value is set to /lib/udev while waiting for
# >=sys-fs/udev-187-r1 to stabilize.
udev_get_udevdir() {
	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
	debug-print-function ${FUNCNAME} "${@}"

	echo -n "${EPREFIX}$(_udev_get_udevdir)"
}

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Samuli Suominen]

On 08/06/2012 01:20 PM, Michał Górny wrote:
> Ok, a few comments from me.

[ ... ]

 >

btw, usb_modeswitch doesn't work if left to /lib/udev with 
 >=sys-fs/udev-187-r1:

http://forums.gentoo.org/viewtopic-t-932338-highlight-.html

now you know why this came up and why I committed the -r2 in tree 
already (and couldn't wait for this eclass review)

- Samuli

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On 06-08-2012 14:02:41 +0300, Samuli Suominen wrote:
> rules files are often small and often get always installed, yet the 
> package might be running just fine without udev, the installed rules 
> files just don't get used
> 
> therefore adding sys-fs/udev dependency to the eclass is out of question 
> and should be left for ebuilds
> 
> therefore pseudo-prefix support should be left in place too... right?

I guess so, or you'll trigger "out of prefix" errors indeed.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Rich Freeman]

On Mon, Aug 6, 2012 at 6:20 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Most importantly, this allows us to easily find out which packages
> install such files and perform global operations on them. For example,
> if a particular user had systemd locations in INSTALL_MASK and changed
> his mind, he can easily update his system by rebuilding all packages
> inheriting systemd.eclass.
>
> If all packages installing udev rules start inheriting it, the above
> will no longer be correct. Also, the opposite way -- rebuilding
> packages installing udev rules -- won't be that easy.

This seems like a bit of overloading.  Right now we really lack a good
way to figure out what packages COULD install files in a given place -
we can only figure out which ones have installed files in that
location on our own systems.

If we really want that capability then I think the solution is to
design it thoughtfully.  Sure, some detective work with eclass
inheritance might give us clues, but I wouldn't let it be a big driver
behind how we use and design eclasses.  That said, there might be
other valid reasons for keeping udev and systemd separate
eclass-wise...

Rich

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Rich Freeman]

On Mon, Aug 6, 2012 at 6:42 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote:
>> > Also, I'm not so sure if this will work correctly for Prefix.
>>
>> I'm sure that is easily checked and we will get feedback quickly.
>
> I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is
> more sensical not to pseudo-provide support for it.
>

I wouldn't be so quick to make that assumption.  Right now openrc
doesn't work on Prefix but there is a SoC project to change that.  Why
wouldn't we assume that somebody will do the same for systemd?
Obviously the long-term future of systemd/openrc/alternatives is
unclear now, but that just seems to be all the more reason to keep our
options open.

I'm not suggesting that we fully build-in support for systemd under
Prefix and so on, but rather I'm suggesting that if leaving it open as
an option now saves us a lot of rework later we should consider it.

(And yes, I realize that systemd is currently linux-only and why that
would make any use under Prefix difficult.)

Rich

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

On 06-08-2012 07:49:48 -0400, Rich Freeman wrote:
> On Mon, Aug 6, 2012 at 6:42 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> > On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote:
> >> > Also, I'm not so sure if this will work correctly for Prefix.
> >>
> >> I'm sure that is easily checked and we will get feedback quickly.
> >
> > I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is
> > more sensical not to pseudo-provide support for it.
> 
> I wouldn't be so quick to make that assumption.  Right now openrc
> doesn't work on Prefix but there is a SoC project to change that.  Why
> wouldn't we assume that somebody will do the same for systemd?
> Obviously the long-term future of systemd/openrc/alternatives is
> unclear now, but that just seems to be all the more reason to keep our
> options open.
> 
> I'm not suggesting that we fully build-in support for systemd under
> Prefix and so on, but rather I'm suggesting that if leaving it open as
> an option now saves us a lot of rework later we should consider it.
> 
> (And yes, I realize that systemd is currently linux-only and why that
> would make any use under Prefix difficult.)

While OpenRC is likely perfectly capable of starting/stopping daemons as
a normal user (with some tweaks), I expect systemd replacing init, to
already have a fair bit of isssues with being just a normal unprivileged
user.  I may be wrong, of course.  However, the notorious reputation of
that piece of software aiming for system-domination doesn't really make
it sound to me like it ever will be a good match for Prefix.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Rich Freeman]

On Mon, Aug 6, 2012 at 7:56 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> While OpenRC is likely perfectly capable of starting/stopping daemons as
> a normal user (with some tweaks), I expect systemd replacing init, to
> already have a fair bit of isssues with being just a normal unprivileged
> user.  I may be wrong, of course.  However, the notorious reputation of
> that piece of software aiming for system-domination doesn't really make
> it sound to me like it ever will be a good match for Prefix.

Yup, hence my final comment.  However, I suspect that the
multitude-of-init-systems is going to be a somewhat temporary
condition for a few years, and after that with the amount of vertical
integration everybody is pushing one may win out.  If that happens,
we'll all be using whatever that ends up being, regardless of whether
it is a good match for Prefix.  If the world remains heterogeneous
then most likely Gentoo will remain as such also, and other than all
the package maintainers having to supply 3 different init scripts for
their pacakges all will be well for Prefix.

Rich

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

On Mon, 6 Aug 2012 07:49:48 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Aug 6, 2012 at 6:42 AM, Fabian Groffen <grobian@gentoo.org>
> wrote:
> > On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote:
> >> > Also, I'm not so sure if this will work correctly for Prefix.
> >>
> >> I'm sure that is easily checked and we will get feedback quickly.
> >
> > I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is
> > more sensical not to pseudo-provide support for it.
> >
> 
> I wouldn't be so quick to make that assumption.  Right now openrc
> doesn't work on Prefix but there is a SoC project to change that.  Why
> wouldn't we assume that somebody will do the same for systemd?
> Obviously the long-term future of systemd/openrc/alternatives is
> unclear now, but that just seems to be all the more reason to keep our
> options open.
> 
> I'm not suggesting that we fully build-in support for systemd under
> Prefix and so on, but rather I'm suggesting that if leaving it open as
> an option now saves us a lot of rework later we should consider it.
> 
> (And yes, I realize that systemd is currently linux-only and why that
> would make any use under Prefix difficult.)

There are Linux prefixes too, aren't there?

I see one use for Prefix systemd unit files currently: when host runs
systemd, and user uses (symlinks) the Gentoo Prefix init files to start
prefixed services on the host.


-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On Mon, 6 Aug 2012 08:05:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Aug 6, 2012 at 7:56 AM, Fabian Groffen <grobian@gentoo.org>
> wrote:
> > While OpenRC is likely perfectly capable of starting/stopping
> > daemons as a normal user (with some tweaks), I expect systemd
> > replacing init, to already have a fair bit of isssues with being
> > just a normal unprivileged user.  I may be wrong, of course.
> > However, the notorious reputation of that piece of software aiming
> > for system-domination doesn't really make it sound to me like it
> > ever will be a good match for Prefix.
> 
> Yup, hence my final comment.  However, I suspect that the
> multitude-of-init-systems is going to be a somewhat temporary
> condition for a few years, and after that with the amount of vertical
> integration everybody is pushing one may win out.  If that happens,
> we'll all be using whatever that ends up being, regardless of whether
> it is a good match for Prefix.  If the world remains heterogeneous
> then most likely Gentoo will remain as such also, and other than all
> the package maintainers having to supply 3 different init scripts for
> their pacakges all will be well for Prefix.

I would be really happy if openrc supported systemd units. Or any other
good unit format but it's probably too late to invent anything here...


-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote:
> While OpenRC is likely perfectly capable of starting/stopping daemons as
> a normal user (with some tweaks), I expect systemd replacing init, to
> already have a fair bit of isssues with being just a normal unprivileged
> user.  I may be wrong, of course.  However, the notorious reputation of
> that piece of software aiming for system-domination doesn't really make
> it sound to me like it ever will be a good match for Prefix.

You happen to be wrong. systemd runs perfectly as non-pid-1. Part of
Lennart's well published plan for world domination is to use systemd as
a session manager, so it would replace gnome-session, etc. Lennart &
friends are currently pushing kernel patches to make it fully recursive
(such as being able to re-parent orphaned processes to the session's
systemd instead of the global one.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On 06-08-2012 11:16:52 -0700, Olivier Crête wrote:
> On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote:
> > While OpenRC is likely perfectly capable of starting/stopping daemons as
> > a normal user (with some tweaks), I expect systemd replacing init, to
> > already have a fair bit of isssues with being just a normal unprivileged
> > user.  I may be wrong, of course.  However, the notorious reputation of
> > that piece of software aiming for system-domination doesn't really make
> > it sound to me like it ever will be a good match for Prefix.
> 
> You happen to be wrong. systemd runs perfectly as non-pid-1. Part of
> Lennart's well published plan for world domination is to use systemd as
> a session manager, so it would replace gnome-session, etc. Lennart &
> friends are currently pushing kernel patches to make it fully recursive
> (such as being able to re-parent orphaned processes to the session's
> systemd instead of the global one.

Good to know that I'm wrong.  I didn't know they pursued world
domination too.  I wonder how "kernel patches" go well together with
"being in an environment unknown to you, or that you cannot control at
all", though.  Seems there is interest for it to support Prefix then.
Looking forward to patches and solutions to complement the challenges of
this year's GSoC task.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

On Mon, 2012-08-06 at 20:28 +0200, Fabian Groffen wrote:
> On 06-08-2012 11:16:52 -0700, Olivier Crête wrote:
> > On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote:
> > > While OpenRC is likely perfectly capable of starting/stopping daemons as
> > > a normal user (with some tweaks), I expect systemd replacing init, to
> > > already have a fair bit of isssues with being just a normal unprivileged
> > > user.  I may be wrong, of course.  However, the notorious reputation of
> > > that piece of software aiming for system-domination doesn't really make
> > > it sound to me like it ever will be a good match for Prefix.
> > 
> > You happen to be wrong. systemd runs perfectly as non-pid-1. Part of
> > Lennart's well published plan for world domination is to use systemd as
> > a session manager, so it would replace gnome-session, etc. Lennart &
> > friends are currently pushing kernel patches to make it fully recursive
> > (such as being able to re-parent orphaned processes to the session's
> > systemd instead of the global one.
> 
> Good to know that I'm wrong.  I didn't know they pursued world
> domination too.  I wonder how "kernel patches" go well together with
> "being in an environment unknown to you, or that you cannot control at
> all", though.  Seems there is interest for it to support Prefix then.
> Looking forward to patches and solutions to complement the challenges of
> this year's GSoC task.

I think they only want to support systemd-in-systemd, not
systemd-in-random-init-system.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On 06-08-2012 11:40:57 -0700, Olivier Crête wrote:
> I think they only want to support systemd-in-systemd, not
> systemd-in-random-init-system.

I think neither fits Prefix.  So we're back at the starting position.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]