public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] new eclass: tmpfiles.eclass for handling tmpfiles.d files
Date: Tue, 15 Nov 2016 14:26:55 -0600	[thread overview]
Message-ID: <20161115202655.GA20905@whubbs1.gaikai.biz> (raw)
In-Reply-To: <20161115210720.637d1f25.mgorny@gentoo.org>

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

On Tue, Nov 15, 2016 at 09:07:20PM +0100, Michał Górny wrote:
> On Tue, 15 Nov 2016 13:42:00 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > # Copyright 1999-2016 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Id$
> > 
> > # @ECLASS: tmpfiles.eclass
> > # @MAINTAINER:
> > # Gentoo systemd project <systemd@gentoo.org>
> > # William Hubbs <williamh@gentoo.org>
> > # @AUTHOR:
> > # Mike Gilbert <floppym@gentoo.org>
> > # William Hubbs <williamh@gentoo.org>
> > # @BLURB: Functions related to tmpfiles.d files
> > # @DESCRIPTION:
> > # Provides common functionality related to installation an processing
> 
> Typo: 'and'
> 
> > # of tmpfiles snippets.
> 
> Honestly, I would like to see here either a more complete description
> (with example!) on what purpose does this eclass serve and how it's
> supposed to be used.
> 
> It would probably make sense to explain that it can be used to
> *reliably* create temporary directories, i.e. without a need for
> an explicit fallback in ebuild. After all, that's the main goal of
> the whole effort.
 
 Sure, I'll add more info here.

> It may also be worth it to note that full support requires OpenRC or
> systemd. People not using either of the two will only get directories
> created in postinst, and can't use volatile filesystems.

The only thing another init system would have to do is run opentmpfiles
or systemd-tmpfiles at the appropriate point in bootup, so I can mention
that.

> 
> > if [[ -z $tmpfiles_eclass ]]; then
> 
> 1. Don't indent the whole eclass.
> 
> 2. Use capitals for global variables.
> 
> 3. Use ${} with braces.
> 
> > 	tmpfiles_eclass=1
> > 
> > 	case "${EAPI}" in
> > 		5|6) ;;
> > 		*) die "API is undefined for EAPI ${EAPI}" ;;
> > 	esac
> > 
> > 	DEPEND="virtual/tmpfiles"
> 
> You don't need build-time dependency on it. It's not used before pkg_*.
> 
> > 	RDEPEND="virtual/tmpfiles"
> 
> 1. I'm wondering if there's a case for making this optional
> (I'm pretty sure we have USE-conditional installs of tmpfiles, however
> I'm not sure if we care for 100% exact deps).
 
hmm, use-conditional installs of tmpfiles... should we look into fixing
those (wrt our practice of always installing small files), or should we
revisit that whole practice (+1000 for revisiting it).

RDEPEND's can't depend on use flags, so I'm not sure how we would make
this optional.

> 2. I think it would be reasonable to match virtual versions to
> 'versions' of tmpfiles.d support, i.e. to be able to e.g. >=230 when
> the file needs new feature that was introduced in systemd-230. But
> maybe it'd good enough to have additional dependency in ebuild then.
> 

I'm not sure about adding an additional dependency to the ebuild. This
could be handled by bumping the virtual if necessary.

> ...
> > 	# @FUNCTION: tmpfiles_create
> 
> Maybe tmpfiles_process?
> 
> > 	# @USAGE: tmpfiles_create
> 
> I think you actually want to pass filenames here.
> 
> > 	# @DESCRIPTION:
> > 	# Call a tmpfiles implementation to process newly installed tmpfiles.d
> > 	# snippets. Does nothing if no tmpfiles implementation is available.
> 
> I think it should error out when no implementation is available. We
> want to be able to reliably create temporary directories.
> 
> > 	tmpfiles_create() {
> > 		debug-print-function "${FUNCNAME}" "$@"
> > 
> > 		[[ ${EBUILD_PHASE} == postinst ]] || die "${FUNCNAME}: Only valid in pkg_postinst"
> > 		[[ ${#} -gt 0 ]] || die "${FUNCNAME}: Must specify at least one filename"
> > 		[[ ${ROOT} == / ]] || return 0
> > 
> > 		if type systemd-tmpfiles &> /dev/null; then
> > 			systemd-tmpfiles --create "$@"
> > 		elif type opentmptmpfiles &> /dev/null; then
> > 			opentmpfiles --create "$@"
> > 		fi
> > 	}
> > 
> > fi
> 
> I'm wondering if we could go for some cleanup in prerm. But that's
> probably a far-away future goal.
> 
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>



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

  reply	other threads:[~2016-11-15 20:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 19:42 [gentoo-dev] new eclass: tmpfiles.eclass for handling tmpfiles.d files William Hubbs
2016-11-15 19:59 ` Mike Gilbert
2016-11-15 20:07 ` Michał Górny
2016-11-15 20:26   ` William Hubbs [this message]
2016-11-15 20:59     ` Michał Górny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161115202655.GA20905@whubbs1.gaikai.biz \
    --to=williamh@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox