From: "Michał Górny" <mgorny@gentoo.org>
To: Ian Stakenvicius <axs@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] tmpfiles virtual
Date: Thu, 17 Nov 2016 19:46:41 +0100 [thread overview]
Message-ID: <20161117194641.29a18b91.mgorny@gentoo.org> (raw)
In-Reply-To: <b6ab79ff-6727-0e37-5bd7-c71d4811c11f@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
On Thu, 17 Nov 2016 10:02:25 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 17/11/16 01:03 AM, Michał Górny wrote:
> > On Wed, 16 Nov 2016 14:21:41 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> >
> >> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote:
> >>> On 16/11/16 12:03 PM, William Hubbs wrote:
> >>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote:
> >>>>> On 16/11/16 10:08 AM, William Hubbs wrote:
> >>>>>> opentmpfiles will be updated to install the service scripts which
> >>>>>> will be run when OpenRC boots a system. There is nothing for
> >>>>>> it to do if systemd is used to boot the system.
> >>>>>>
> >>>>>> William
> >>>>>>
> >>>>>
> >>>>> But there is something to do if openrc is used to boot the system and
> >>>>> systemd is the package providing tmpfiles.d processing via the virtual.
> >>>>
> >>>> The providers (opentmpfiles and systemd) will not block each other, so
> >>>> the only way this will happen is if you have openrc and systemd
> >>>> installed then forcefully remove opentmpfiles. I think you would not
> >>>> want to do that until you are ready to migrate to booting with systemd.
> >>>>
> >>>> William
> >>>>
> >>>
> >>> I think I'm having a hard time getting across the issue here...:
> >>>
> >>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
> >>> or opentmpfiles.
> >>>
> >>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)
> >>>
> >>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
> >>> need to depend on virtual/tmpfiles in order to make sure that the
> >>> system has something installed that will process them at boot-time.
> >>
> >> Yes, this will be handled by an RDEPEND in the eclass.
> >
> > This is a wrong presumption. The eclass needs the virtual only for
> > pkg_postinst(). While RDEPEND is how we solve this now, it will no
> > longer be necessary in a future EAPI.
> >
>
> This makes sense to me as well -- which means every package that
> installs tmpfiles.d/ files should properly RDEPEND on the virtual on
> its own when the functionality arisen from those tmpfiles.d files is
> non-optional.
No, that's now what I meant.
The eclass needs the virtual to create temporary directories once,
in pkg_postinst(). Period. That's how far it is concerned.
If user wants to use a volatile filesystem or any other more complete
tmpfiles.d processing, he needs to use a init that supports that. Which
means either OpenRC with tmpfiles or systemd. Ebuild has nothing to do
with this.
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]
next prev parent reply other threads:[~2016-11-17 18:47 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 0:23 [gentoo-dev] tmpfiles virtual William Hubbs
2016-11-15 5:09 ` Michał Górny
2016-11-15 15:49 ` Dustin C. Hatch
2016-11-15 16:50 ` Rich Freeman
2016-11-15 16:56 ` Michał Górny
2016-11-15 17:56 ` William Hubbs
2016-11-15 18:57 ` Ian Stakenvicius
2016-11-15 19:42 ` Michał Górny
2016-11-15 19:51 ` Ian Stakenvicius
2016-11-15 19:56 ` Mike Gilbert
2016-11-16 13:57 ` Ian Stakenvicius
2016-11-16 15:08 ` William Hubbs
2016-11-16 15:14 ` Ian Stakenvicius
2016-11-16 17:03 ` William Hubbs
2016-11-16 18:04 ` Ian Stakenvicius
2016-11-16 20:21 ` William Hubbs
2016-11-16 23:09 ` Ian Stakenvicius
2016-11-16 23:16 ` William Hubbs
2016-11-16 23:19 ` Ian Stakenvicius
2016-11-16 23:25 ` William Hubbs
2016-11-16 23:45 ` Ian Stakenvicius
2016-11-17 1:41 ` Rich Freeman
2016-11-17 2:19 ` Mike Gilbert
2016-11-17 4:16 ` Ian Stakenvicius
2016-11-17 21:58 ` [gentoo-dev] " Martin Vaeth
2016-11-18 0:41 ` Rich Freeman
2016-11-17 0:09 ` [gentoo-dev] " Mike Gilbert
2016-11-17 6:03 ` Michał Górny
2016-11-17 15:02 ` Ian Stakenvicius
2016-11-17 17:22 ` William Hubbs
2016-11-17 19:00 ` Ian Stakenvicius
2016-11-17 18:46 ` Michał Górny [this message]
2016-11-17 18:49 ` Michał Górny
2016-11-17 19:01 ` William Hubbs
2016-11-17 19:10 ` Ian Stakenvicius
2016-11-17 19:42 ` Michał Górny
2016-11-17 20:07 ` Ian Stakenvicius
2016-11-17 20:21 ` Rich Freeman
2016-11-17 21:38 ` [gentoo-dev] " Martin Vaeth
2016-11-17 20:50 ` [gentoo-dev] " Michał Górny
2016-11-17 22:19 ` Ian Stakenvicius
2016-11-15 17:11 ` Mike Gilbert
2016-11-15 18:22 ` William Hubbs
2016-11-15 19:40 ` Michał Górny
2016-11-18 18:42 ` William Hubbs
2016-11-18 18:46 ` Mike Gilbert
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=20161117194641.29a18b91.mgorny@gentoo.org \
--to=mgorny@gentoo.org \
--cc=axs@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