systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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...
# 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)"
}

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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

systemd.eclass: Patch for new function systemd_get_udevdir()
 

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