[gentoo-dev] new eclass: systemd-next.eclass

[gentoo-dev] new eclass: systemd-next.eclass

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 564 bytes --]

All,

this eclass is an alternative to systemd.eclass, and maintains
full compatibility with it; however, it expands it so that it can query
pkgconfig for the directory paths. It returns the same default paths as
systemd.eclass if there is an error with pkgconfig.

I am sending this out for review so we can commit it to the tree
when we commit our alternate systemd ebuild in a few days. This will be
set up so that users can choose which systemd package they want to
install, and it will default to the current systemd package.

Thanks,

the systemd-next team


[-- Attachment #1.2: systemd-next.eclass --]
[-- Type: text/plain, Size: 7287 bytes --]

# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/systemd.eclass,v 1.22 2013/03/18 06:29:03 mgorny Exp $

# @ECLASS: systemd-next.eclass
# @MAINTAINER:
# williamh@gentoo.org
# ssuominen@gentoo.org
# @BLURB: helper functions to install systemd units
# @DESCRIPTION:
# This eclass provides a set of functions to install unit files for
# systemd within ebuilds. It maintains compatibility with
# systemd.eclass by default, but it also allows querying pkgconfig.
#
# @EXAMPLE:
#
# @CODE
# inherit autotools-utils systemd-next
#
# src_configure() {
#	local myeconfargs=(
#		--enable-foo
#		--disable-bar
#	)
#
#	systemd_to_myeconfargs
#	autotools-utils_src_configure
# }
# @CODE

inherit toolchain-funcs

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

DEPEND="virtual/pkgconfig"

# @FUNCTION: _systemd_get_unitdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed unitdir.
_systemd_get_unitdir() {
	if $($(tc-getPKG_CONFIG) --exists systemd); then
		echo "$($(tc-getPKG_CONFIG) --variable=systemdsystemunitdir systemd)"
	else
		echo /usr/lib/systemd/system
	fi
}

# @FUNCTION: systemd_get_unitdir
# @DESCRIPTION:
# Output the path for the systemd unit directory (not including ${D}).
# This function always succeeds, even if systemd is not installed.
systemd_get_unitdir() {
	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
	debug-print-function ${FUNCNAME} "${@}"

	echo "${EPREFIX}$(_systemd_get_unitdir)"
}

# @FUNCTION: _systemd_get_userunitdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed userunitdir.
_systemd_get_userunitdir() {
	if $($(tc-getPKG_CONFIG) --exists systemd); then
		echo "$($(tc-getPKG_CONFIG) --variable=systemduserunitdir systemd)"
	else
		echo /usr/lib/systemd/user
	fi
}

# @FUNCTION: systemd_get_userunitdir
# @DESCRIPTION:
# Output the path for the systemd user unit directory (not including
# ${D}). This function always succeeds, even if systemd is not
# installed.
systemd_get_userunitdir() {
	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
	debug-print-function ${FUNCNAME} "${@}"

	echo "${EPREFIX}$(_systemd_get_userunitdir)"
}

# @FUNCTION: _systemd_get_utildir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed utildir.
_systemd_get_utildir() {
	if $($(tc-getPKG_CONFIG) --exists systemd); then
		echo "$($(tc-getPKG_CONFIG) --variable=systemdutildir systemd)"
	else
		echo /usr/lib/systemd
	fi
}

# @FUNCTION: systemd_get_utildir
# @DESCRIPTION:
# Output the path for the systemd utility directory (not including
# ${D}). This function always succeeds, even if systemd is not
# installed.
systemd_get_utildir() {
	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
	debug-print-function ${FUNCNAME} "${@}"

	echo "${EPREFIX}$(_systemd_get_utildir)"
}

# @FUNCTION: systemd_dounit
# @USAGE: unit1 [...]
# @DESCRIPTION:
# Install systemd unit(s). Uses doins, thus it is fatal in EAPI 4
# and non-fatal in earlier EAPIs.
systemd_dounit() {
	debug-print-function ${FUNCNAME} "${@}"

	local INSDESTTREE
	insinto "$(_systemd_get_unitdir)"
	doins "${@}"
}

# @FUNCTION: systemd_newunit
# @USAGE: oldname newname
# @DESCRIPTION:
# Install systemd unit with a new name. Uses newins, thus it is fatal
# in EAPI 4 and non-fatal in earlier EAPIs.
systemd_newunit() {
	debug-print-function ${FUNCNAME} "${@}"

	local INSDESTTREE
	insinto "$(_systemd_get_unitdir)"
	newins "${@}"
}

# @FUNCTION: systemd_dotmpfilesd
# @USAGE: tmpfilesd1 [...]
# @DESCRIPTION:
# Install systemd tmpfiles.d files. Uses doins, thus it is fatal
# in EAPI 4 and non-fatal in earlier EAPIs.
systemd_dotmpfilesd() {
	debug-print-function ${FUNCNAME} "${@}"

	for f; do
		[[ ${f} == *.conf ]] \
			|| die 'tmpfiles.d files need to have .conf suffix.'
	done

	local INSDESTTREE
	insinto /usr/lib/tmpfiles.d/
	doins "${@}"
}

# @FUNCTION: systemd_newtmpfilesd
# @USAGE: oldname newname.conf
# @DESCRIPTION:
# Install systemd tmpfiles.d file under a new name. Uses newins, thus it
# is fatal in EAPI 4 and non-fatal in earlier EAPIs.
systemd_newtmpfilesd() {
	debug-print-function ${FUNCNAME} "${@}"

	[[ ${2} == *.conf ]] \
		|| die 'tmpfiles.d files need to have .conf suffix.'

	local INSDESTTREE
	insinto /usr/lib/tmpfiles.d/
	newins "${@}"
}

# @FUNCTION: systemd_enable_service
# @USAGE: target service
# @DESCRIPTION:
# Enable service in desired target, e.g. install a symlink for it.
# Uses dosym, thus it is fatal in EAPI 4 and non-fatal in earlier
# EAPIs.
systemd_enable_service() {
	debug-print-function ${FUNCNAME} "${@}"

	[[ ${#} -eq 2 ]] || die "Synopsis: systemd_enable_service target service"

	local target=${1}
	local service=${2}
	local ud=$(_systemd_get_unitdir)
	local destname=$(basename "${service}")

	dodir "${ud}"/"${target}".wants && \
	dosym ../"${service}" "${ud}"/"${target}".wants/"${destname}"
}

# @FUNCTION: systemd_with_unitdir
# @USAGE: [configure option]
# @DESCRIPTION:
# Output '--with-systemdsystemunitdir' as expected by systemd-aware configure
# scripts. This function always succeeds. Its output may be quoted in order
# to preserve whitespace in paths. If you are using autotools-utils,
# systemd_to_myeconfargs() is preferred over this function.
#
# If upstream uses an invalid configure option to handle installing systemd
# units (e.g. `--with-systemdunitdir'), you can pass the 'suffix' as an optional
# argument to this function (`$(systemd_with_unitdir systemdunitdir)'). Please
# remember to report a bug upstream as well.
systemd_with_unitdir() {
	debug-print-function ${FUNCNAME} "${@}"
	local optname=${1:-systemdsystemunitdir}

	echo --with-${optname}="$(systemd_get_unitdir)"
}

# @FUNCTION: systemd_with_utildir
# @DESCRIPTION:
# Output '--with-systemdsystemutildir' as used by some packages to install
# systemd helpers. This function always succeeds. Its output may be quoted
# in order to preserve whitespace in paths.
systemd_with_utildir() {
	debug-print-function ${FUNCNAME} "${@}"

	echo --with-systemdutildir="$(systemd_get_utildir)"
}

# @FUNCTION: systemd_to_myeconfargs
# @DESCRIPTION:
# Add '--with-systemdsystemunitdir' as expected by systemd-aware configure
# scripts to the myeconfargs variable used by autotools-utils eclass. Handles
# quoting automatically.
systemd_to_myeconfargs() {
	debug-print-function ${FUNCNAME} "${@}"

	myeconfargs=(
		"${myeconfargs[@]}"
		--with-systemdsystemunitdir="$(systemd_get_unitdir)"
	)
}

# @FUNCTION: systemd_update_catalog
# @DESCRIPTION:
# Update the journald catalog. This needs to be called after installing
# or removing catalog files.
#
# If systemd is not installed, no operation will be done. The catalog
# will be (re)built once systemd is installed.
#
# See: http://www.freedesktop.org/wiki/Software/systemd/catalog
systemd_update_catalog() {
	debug-print-function ${FUNCNAME} "${@}"

	# Make sure to work on the correct system.

	local journalctl
	if [[ -x ${EPREFIX}/usr/bin/journalctl ]]; then
		journalctl="${EPREFIX}/usr/bin/journalctl"
	elif [[ -x ${EPREFIX}/bin/journalctl ]]; then
		journalctl="${EPREFIX}"/bin/journalctl
	fi
	if [[ -x ${journalctl} ]]; then
		ebegin "Updating systemd journal catalogs"
		journalctl --update-catalog
		eend $?
	else
		debug-print "${FUNCNAME}: journalctl not found."
	fi
}

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

Re: [gentoo-dev] new eclass: systemd-next.eclass

[Rich Freeman]

On Sat, Apr 13, 2013 at 3:43 PM, William Hubbs <williamh@gentoo.org> wrote:
> I am sending this out for review so we can commit it to the tree
> when we commit our alternate systemd ebuild in a few days. This will be
> set up so that users can choose which systemd package they want to
> install, and it will default to the current systemd package.

Did I miss some kind of announcement for what is going on here?  An
additional implementation in portage along with an eclass probably is
worth some kind of intro on-list.  I don't think you need to seek
approval/etc, but it would be nice to know what your goals/etc are.
Is this just a different installation/configuration approach, or is
this some kind of upstream fork?

Rich

Re: [gentoo-dev] new eclass: systemd-next.eclass

[Diego Elio Pettenò]

It's happening that we seem to have a bunch of crybabies in Gentoo
that don't get along together and instead of figuring out their
differences are going to screw up users even more.

Bunch of chipmunks in our ranks as well I suppose.
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


On Sat, Apr 13, 2013 at 10:15 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sat, Apr 13, 2013 at 3:43 PM, William Hubbs <williamh@gentoo.org> wrote:
>> I am sending this out for review so we can commit it to the tree
>> when we commit our alternate systemd ebuild in a few days. This will be
>> set up so that users can choose which systemd package they want to
>> install, and it will default to the current systemd package.
>
> Did I miss some kind of announcement for what is going on here?  An
> additional implementation in portage along with an eclass probably is
> worth some kind of intro on-list.  I don't think you need to seek
> approval/etc, but it would be nice to know what your goals/etc are.
> Is this just a different installation/configuration approach, or is
> this some kind of upstream fork?
>
> Rich
>

Re: [gentoo-dev] new eclass: systemd-next.eclass

[William Hubbs]

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

On Sat, Apr 13, 2013 at 04:15:03PM -0400, Rich Freeman wrote:
> On Sat, Apr 13, 2013 at 3:43 PM, William Hubbs <williamh@gentoo.org> wrote:
> > I am sending this out for review so we can commit it to the tree
> > when we commit our alternate systemd ebuild in a few days. This will be
> > set up so that users can choose which systemd package they want to
> > install, and it will default to the current systemd package.
> 
> Did I miss some kind of announcement for what is going on here?  An
> additional implementation in portage along with an eclass probably is
> worth some kind of intro on-list.  I don't think you need to seek
> approval/etc, but it would be nice to know what your goals/etc are.
> Is this just a different installation/configuration approach, or is
> this some kind of upstream fork?

It is not an upstream fork, it is a configuration/installation
approach that follows upstream's recommendations for install locations.
It also allows the user more choices wrt which parts of systemd are
built or installed and allows more fine-grained use dependencies for
other packages.

William


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

Re: [gentoo-dev] new eclass: systemd-next.eclass

[Rich Freeman]

On Sat, Apr 13, 2013 at 4:57 PM, William Hubbs <williamh@gentoo.org> wrote:
> It is not an upstream fork, it is a configuration/installation
> approach that follows upstream's recommendations for install locations.
> It also allows the user more choices wrt which parts of systemd are
> built or installed and allows more fine-grained use dependencies for
> other packages.

Thanks.  Might not hurt to document somewhere (wiki/etc) so that users
can make an informed choice and to understand the contrasting
philosophies.

Dennis recently blogged on this topic.  While cooperation should
always be done when possible, if somebody really feels there is value
in having an alternative I really don't see the problem.  The main
concern I'd have is coordination with other packages - for example I'd
hate to see the unit files going into different places since that
would make it impossible for other packages to determine where the
user wants them (units might be installed before either implementation
is installed).  If conflict between alternative implementations starts
creating problems for the rest of the distro then it only makes sense
for the council to step in.

Rich

Re: [gentoo-dev] new eclass: systemd-next.eclass

[Michał Górny]

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

On Sat, 13 Apr 2013 14:43:14 -0500
William Hubbs <williamh@gentoo.org> wrote:

> this eclass is an alternative to systemd.eclass, and maintains
> full compatibility with it; however, it expands it so that it can query
> pkgconfig for the directory paths. It returns the same default paths as
> systemd.eclass if there is an error with pkgconfig.

Alternative? So now developers decide whether they want support systemd
A or systemd B? And we fork packages so that users can have matching
set of packages?

If you listened, you would know that the only reason I didn't apply
your patches to the eclass was that nothing used them. If you really
want to commit your quasi-fork, I will update the eclass. You
don't really have to play silly games like this.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] new eclass: systemd-next.eclass

[William Hubbs]

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

On Sat, Apr 13, 2013 at 11:27:24PM +0200, Michał Górny wrote:
> On Sat, 13 Apr 2013 14:43:14 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > this eclass is an alternative to systemd.eclass, and maintains
> > full compatibility with it; however, it expands it so that it can query
> > pkgconfig for the directory paths. It returns the same default paths as
> > systemd.eclass if there is an error with pkgconfig.
> 
> Alternative? So now developers decide whether they want support systemd
> A or systemd B? And we fork packages so that users can have matching
> set of packages?
> 
> If you listened, you would know that the only reason I didn't apply
> your patches to the eclass was that nothing used them. If you really
> want to commit your quasi-fork, I will update the eclass. You
> don't really have to play silly games like this.

Ok, that is the better aproach anyway, go ahead and update the eclass.

Thanks much. :-)

William


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

Re: [gentoo-dev] new eclass: systemd-next.eclass

[Markos Chandras]

On 13 April 2013 22:30, William Hubbs <williamh@gentoo.org> wrote:
> On Sat, Apr 13, 2013 at 11:27:24PM +0200, Michał Górny wrote:
>> On Sat, 13 Apr 2013 14:43:14 -0500
>> William Hubbs <williamh@gentoo.org> wrote:
>>
>> > this eclass is an alternative to systemd.eclass, and maintains
>> > full compatibility with it; however, it expands it so that it can query
>> > pkgconfig for the directory paths. It returns the same default paths as
>> > systemd.eclass if there is an error with pkgconfig.
>>
>> Alternative? So now developers decide whether they want support systemd
>> A or systemd B? And we fork packages so that users can have matching
>> set of packages?
>>
>> If you listened, you would know that the only reason I didn't apply
>> your patches to the eclass was that nothing used them. If you really
>> want to commit your quasi-fork, I will update the eclass. You
>> don't really have to play silly games like this.
>
> Ok, that is the better aproach anyway, go ahead and update the eclass.
>
> Thanks much. :-)
>
> William
>

Am I the only one wondering why you didn't discuss this before you
submit a new eclass for review?

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] new eclass: systemd-next.eclass

[William Hubbs]

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

On Sun, Apr 14, 2013 at 12:41:59AM +0100, Markos Chandras wrote:
> On 13 April 2013 22:30, William Hubbs <williamh@gentoo.org> wrote:
> > On Sat, Apr 13, 2013 at 11:27:24PM +0200, Michał Górny wrote:
> >> On Sat, 13 Apr 2013 14:43:14 -0500
> >> William Hubbs <williamh@gentoo.org> wrote:
> >>
> >> > this eclass is an alternative to systemd.eclass, and maintains
> >> > full compatibility with it; however, it expands it so that it can query
> >> > pkgconfig for the directory paths. It returns the same default paths as
> >> > systemd.eclass if there is an error with pkgconfig.
> >>
> >> Alternative? So now developers decide whether they want support systemd
> >> A or systemd B? And we fork packages so that users can have matching
> >> set of packages?
> >>
> >> If you listened, you would know that the only reason I didn't apply
> >> your patches to the eclass was that nothing used them. If you really
> >> want to commit your quasi-fork, I will update the eclass. You
> >> don't really have to play silly games like this.
> >
> > Ok, that is the better aproach anyway, go ahead and update the eclass.
> >
> > Thanks much. :-)
> >
> > William
> >
> 
> Am I the only one wondering why you didn't discuss this before you
> submit a new eclass for review?

I'm answering this on the list here for completeness only. I feel like a
question here calls for a response.

This started with this thread [1], where I proposed a patch to the
systemd eclass. That patch was rejected as you can see with no real
explanation from mgorny. This lead to private discussions with him which
did not go well. I have all of those emails still, so I will go back and
see if I can find where he gave me the explanation he is claiming here,
but I honestly do not remember any such explanation coming from him
until now.

My original patch has been accepted now, so that should take care of that
part of the situation.

Mgorny, thanks for working with me. :-)

William

[1] http://www.gossamer-threads.com/lists/gentoo/dev/269385?page=last

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

Re: [gentoo-dev] new eclass: systemd-next.eclass

[Michał Górny]

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

On Sat, 13 Apr 2013 19:49:26 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Apr 14, 2013 at 12:41:59AM +0100, Markos Chandras wrote:
> > On 13 April 2013 22:30, William Hubbs <williamh@gentoo.org> wrote:
> > > On Sat, Apr 13, 2013 at 11:27:24PM +0200, Michał Górny wrote:
> > >> On Sat, 13 Apr 2013 14:43:14 -0500
> > >> William Hubbs <williamh@gentoo.org> wrote:
> > >>
> > >> > this eclass is an alternative to systemd.eclass, and maintains
> > >> > full compatibility with it; however, it expands it so that it can query
> > >> > pkgconfig for the directory paths. It returns the same default paths as
> > >> > systemd.eclass if there is an error with pkgconfig.
> > >>
> > >> Alternative? So now developers decide whether they want support systemd
> > >> A or systemd B? And we fork packages so that users can have matching
> > >> set of packages?
> > >>
> > >> If you listened, you would know that the only reason I didn't apply
> > >> your patches to the eclass was that nothing used them. If you really
> > >> want to commit your quasi-fork, I will update the eclass. You
> > >> don't really have to play silly games like this.
> > >
> > > Ok, that is the better aproach anyway, go ahead and update the eclass.
> > >
> > > Thanks much. :-)
> > >
> > > William
> > >
> > 
> > Am I the only one wondering why you didn't discuss this before you
> > submit a new eclass for review?
> 
> I'm answering this on the list here for completeness only. I feel like a
> question here calls for a response.
> 
> This started with this thread [1], where I proposed a patch to the
> systemd eclass. That patch was rejected as you can see with no real
> explanation from mgorny.

For completeness -- there was no real explanation because I explained
why I don't want to change that in the previous thread you started,
and you nevertheless ignored me and submitted the patch.

-- 
Best regards,
Michał Górny

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