From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D49B41395E2 for ; Thu, 17 Nov 2016 22:20:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A7958E0B77; Thu, 17 Nov 2016 22:20:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 41831E09B2 for ; Thu, 17 Nov 2016 22:20:11 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM7cb21bc3014a.cpe.net.cable.rogers.com [174.116.156.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id A4869341597; Thu, 17 Nov 2016 22:20:09 +0000 (UTC) Subject: Re: [gentoo-dev] tmpfiles virtual To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= References: <20161115175601.GA20317@whubbs1.gaikai.biz> <1aab24d7-43d0-d804-e943-dd4993398630@gentoo.org> <20161115204235.07f39850.mgorny@gentoo.org> <0fb71c42-9033-a77b-2a7b-3a7865ce10fe@gentoo.org> <2b376e60-26a1-04bf-44ba-fc07d8da4b7a@gentoo.org> <20161116150823.GA18287@linux1.gaikai.biz> <91eafc74-1fd4-e9cf-e5e6-687ff2cc53df@gentoo.org> <20161116170312.GA24186@whubbs1.gaikai.biz> <20161116202141.GA24625@whubbs1.gaikai.biz> <20161117070323.5618e430.mgorny@gentoo.org> <20161117194641.29a18b91.mgorny@gentoo.org> <20161117194907.16a47779.mgorny@gentoo.org> <20161117204239.00d2cde4.mgorny@gentoo.org> <4049db0f-0a9a-2605-46f5-d456069b78ba@gentoo.org> <20161117215021.70b5ac48.mgorny@gentoo.org> Cc: gentoo-dev@lists.gentoo.org From: Ian Stakenvicius Message-ID: Date: Thu, 17 Nov 2016 17:19:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20161117215021.70b5ac48.mgorny@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LCMe1Gin3nJoAMfBoTetSkNCRmKNPX7LX" X-Archives-Salt: 31c80354-3ecc-4122-8d9a-06aa8112cba1 X-Archives-Hash: f814e827db69beddf1e040c0cdc5d0c3 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LCMe1Gin3nJoAMfBoTetSkNCRmKNPX7LX Content-Type: multipart/mixed; boundary="Imn79GP89wSQijVQsjXxneBAwmfdngjBE" From: Ian Stakenvicius To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org Message-ID: Subject: Re: [gentoo-dev] tmpfiles virtual References: <20161115175601.GA20317@whubbs1.gaikai.biz> <1aab24d7-43d0-d804-e943-dd4993398630@gentoo.org> <20161115204235.07f39850.mgorny@gentoo.org> <0fb71c42-9033-a77b-2a7b-3a7865ce10fe@gentoo.org> <2b376e60-26a1-04bf-44ba-fc07d8da4b7a@gentoo.org> <20161116150823.GA18287@linux1.gaikai.biz> <91eafc74-1fd4-e9cf-e5e6-687ff2cc53df@gentoo.org> <20161116170312.GA24186@whubbs1.gaikai.biz> <20161116202141.GA24625@whubbs1.gaikai.biz> <20161117070323.5618e430.mgorny@gentoo.org> <20161117194641.29a18b91.mgorny@gentoo.org> <20161117194907.16a47779.mgorny@gentoo.org> <20161117204239.00d2cde4.mgorny@gentoo.org> <4049db0f-0a9a-2605-46f5-d456069b78ba@gentoo.org> <20161117215021.70b5ac48.mgorny@gentoo.org> In-Reply-To: <20161117215021.70b5ac48.mgorny@gentoo.org> --Imn79GP89wSQijVQsjXxneBAwmfdngjBE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/11/16 03:50 PM, Micha=C5=82 G=C3=B3rny wrote: > On Thu, 17 Nov 2016 15:07:32 -0500 > Ian Stakenvicius wrote: >> >> OpenRC's init scripts all do that already, more or less. tmpfiles.d >> *.conf files are not used for this purpose -- definitely not by >> OpenRC, and most likely also not by upstream packages. >=20 > So do you expect all eix users to have to run an init script for eix to= > be able to use it? >=20 They already do -- said init script is called tmpfiles.setup and as you already know it's a requirement due to /var/cache/eix needing to be portage:portage and exist despite there not being a guarantee of /var/cache being preserved. >>> The whole point of the eclass is to provide a reasonable way to combi= ne >>> both without having to do the same thing twice. That is, create >>> the directory in postinst and install a tmpfiles.d entry to make it >>> possible to recreate it on boot. =20 >> >> I thought the reason for the eclass was so that when a package is >> installed, you don't need to reboot or otherwise trigger manually your= >> system's tmpfiles.d processing to have it do the first-run process >> with the new *.conf file? >=20 > Yes. That is, to have the temporary directories/files created and/or > permissions set without having to reboot your system. Or to do that > manually in the ebuild, when you're already installing a well-defined > file that explains how to do that. Right -- I presume that said file is usually being provided by upstream, rather than the package maintainer, though? Because there should be very few instances so far as I know that gentoo dev's would need to create tmpfiles.d *.conf files as part of their packaging efforts= =2E >>> If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d= >>> implementation more than to run postinst. =20 >> >> Sure he does. eix needs it to ensure files exist in /var/cache/ , for= >> instance. dhcpd needs it to ensure /var/lib/dhcpd/dhcpd.leases exists= >> and has the correct permissions. Neither of those has got anything to= >> do with openrc's needs at boot time. Whether it's openrc or a fork of= >> upstart or some strange busybox-only script or whatever init/rc system= >> that's used, opentmpfiles provides the capability of processing these >> tmpfiles.d *.conf files and can be triggered at boot time to do it (or= >> via cron, or with it being started as a daemon maybe later I presume) >=20 > You're missing the point. A purely minimal OpenRC-free system with no > volatile filesystems doesn't require any specific action at boot. It's > perfectly happy with the directories created by ebuild. Why would you > require the user of that system to install a tool he won't be using > anyway? When you say 'volatile filesystems' I assume then you're ignoring FHS paths where there are no persistence guarantees? Just because there's no tmpfs doesn't mean there's no volatility.. >=20 >>> After postinst, the directory >>> is created and the user is happy. However, if he uses OpenRC, then >>> OpenRC will make sure the directory disappears on next boot. >>> >>> So why should ebuild add dependencies to solve a limitation caused by= >>> OpenRC? =20 >> >> This would be because opentmpfiles is its own project now rather than >> something shipped as part of (or even needed by) openrc. And so, it's= >> now a runtime dep *when and only when* not processing the tmpfiles.d >> *.conf file is going to make the package fail at runtime, internally >> and intrinsically to the package itself (not to its init script or any= >> other init/rc related thing). >=20 > Are you going to expect all packages with init scripts to depend > on OpenRC now, because your common-assumed use case requires the init > script to do something? Should we also make them depend on systemd at > the same time for completeness? And possibly on bash, vim, etc. so that= > all those extra files get really used. >=20 No. That would be unnecessary as there is, afaik, the requirement of SOME sort of init or rc system in @system already right? The thing is, in THIS case, OpenRC upstream is washing their hands of it. Which means, its up to the new package that actually -does- the processing to install an init script that calls itself (which makes sense) if openrc is booted. All fine and dandy except: #1, we should have something other than the end-user's @world to make sure this is installed (hence RDEPEND on it in packages that need it to be run) because openrc isn't apparently going to depend on it, #2 we need to somehow reconcile the fact that if systemd is installed despite openrc being booted, there still won't be any init scripts because the virtual won't bring in opentmpfiles. And #3, we need a clean way to make openrc actually start the init scripts when they're present and not start them when they're not, since openrc itself isn't carrying them. Now as i said before, i _am_ in agreement with you that all of this would be easier to just have integrated in openrc -- if openrc (the ebuild, not the upstream) RDEPENDs on the virtual and installs tmpfiles.dev and tmpfiles.setup init scripts that call either opentmpfiles or systemd-tmpfilesd, that would sweep all three of the above points under the rug and everything would work better than now. People using something other an init/rc system other than openrc and systemd aren't really supported anyways, so we can just leave it at that.= >> ----- >> >> Part of what you brought up here did trigger a bit of a concern for me= >> though, and that is, we want to be careful that we as developers and >> package maintainers don't start using this eclass and tmpfiles.d >> *.conf files -instead of- keepdir. I'm hoping that this was never the= >> intention, but in case it was I wanted to check. >=20 > It is the intention whenever the directory is volatile. In other words,= > whenever Portage already spits a big QA warning that your keepdir is > not going to survive a reboot and/or cache cleanup. *nod* that makes sense. I assume most of these files are coming from upstream though right? --Imn79GP89wSQijVQsjXxneBAwmfdngjBE-- --LCMe1Gin3nJoAMfBoTetSkNCRmKNPX7LX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAlguLQ8ACgkQ2ugaI38ACPBIswD/cann7sWR+k4KftiQqWckMq7X xil+r1Kwnp1hvaDV7SAA/3yCGg90teHxN2SOGpc4RZxHaVnRXrWMvcj6h6lduagl =zUQh -----END PGP SIGNATURE----- --LCMe1Gin3nJoAMfBoTetSkNCRmKNPX7LX--