Change add by from https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/portage?id=e5f430619b1dbdce1d9ba7836db55fee065798dd Now portage inherit the RDEPEND="kernel_linux? ( virtual/tmpfiles )" Because of this, it mean portage depends on something it doesn't use, and this block users who doesn't use virtual/tmpfiles (users without systemd or openrc, users with an openrc version < date when tmpfiles support was add). And this just for that function! "dotmpfiles" Reproducible: Always Actual Results: portage now indirectly depend on a special init system, while portage itself do not use any function from any special init system. Expected Results: portage should keep depending on packages it use ONLY, portage shouldn't depend on any init system as long as portage has no need for anything for an init system. And this could be easy fix: - revert the change to get back to "-inherit distutils-r1 git-r3" - change dotmpfiles "${FILESDIR}"/portage-ccache.conf with insinto /usr/lib/tmpfiles.d doins "${FILESDIR}"/portage-ccache.conf
(In reply to nobody from comment #0) > And this could be easy fix: > - revert the change to get back to "-inherit distutils-r1 git-r3" > - change dotmpfiles "${FILESDIR}"/portage-ccache.conf with > insinto /usr/lib/tmpfiles.d > doins "${FILESDIR}"/portage-ccache.conf Yeah that seems like a reasonable solution.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=72533ec33e2fa41ac5f9859a4e1826a1baac512a commit 72533ec33e2fa41ac5f9859a4e1826a1baac512a Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-01-04 23:55:17 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-01-04 23:56:38 +0000 sys-apps/portage: eliminate virtual/tmpfiles dependency Closes: https://bugs.gentoo.org/643386 Package-Manager: Portage-2.3.19, Repoman-2.3.6 sys-apps/portage/portage-2.3.19-r1.ebuild | 7 ++++--- sys-apps/portage/portage-9999.ebuild | 7 ++++--- 2 files changed, 8 insertions(+), 6 deletions(-)
This is simply wrong. We use standards so that people don't end up reinventing the wheel every week. tmpfiles doesn't require any init system but merely a tool that's run at postinst.
For OpenRC users, virtual/tmpfiles effectively forces a recent version of sys-apps/openrc via RDEPEND="!<sys-apps/openrc-0.23". Portage doesn't require a virtual/tmpfiles implementation, it only needs to prevent systemd from interfering with /var/tmp/cache.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=302eff51953f1258205feba67936bfb779fc3478 commit 302eff51953f1258205feba67936bfb779fc3478 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-01-05 00:19:22 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-01-05 00:20:10 +0000 sys-apps/portage: use systemd eclass for tmpfiles support Closes: https://bugs.gentoo.org/643386 Package-Manager: Portage-2.3.19, Repoman-2.3.6 sys-apps/portage/portage-2.3.19-r1.ebuild | 5 ++--- sys-apps/portage/portage-9999.ebuild | 5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-)
The !<sys-apps/openrc-0.23 blocker should not be as relevant these days, since the most recent blocked release is nearly 4 years old now (it was only 1 year and 2 months old at the time this bug was opened): https://github.com/OpenRC/openrc/releases/tag/0.22.4
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2af9e69f3462abfcf97679a24897b708f522059e commit 2af9e69f3462abfcf97679a24897b708f522059e Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-09-06 17:16:26 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-09-06 17:35:20 +0000 sys-apps/portage: Migrate to tmpfiles eclass The systemd_dotmpfilesd function is deprecated. Note that this effectively forces upgrade to >=sys-apps/openrc-0.23 for OpenRC users, since opentmpfiles blocks older versions of OpenRC (bug 643386). This should be acceptable, since the older OpenRC versions are nearly 4 years old now. Closes: https://bugs.gentoo.org/740600 Bug: https://bugs.gentoo.org/490676 Bug: https://bugs.gentoo.org/643386 Bug: https://bugs.gentoo.org/740638 Package-Manager: Portage-3.0.5, Repoman-3.0.1 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/portage-2.3.103-r1.ebuild | 4 ++-- sys-apps/portage/portage-2.3.99-r2.ebuild | 4 ++-- sys-apps/portage/portage-3.0.4-r1.ebuild | 4 ++-- sys-apps/portage/portage-3.0.5.ebuild | 4 ++-- sys-apps/portage/portage-9999.ebuild | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-)
Re-opening this because the opentmpfiles dependency added by tmpfiles.eclass is completely unnecessary. The tmpfiles.d config from bug 490676 is only necessary for systemd users.
For what it's worth, I don't see any real problem with calling insinto and doins directly. The /usr/lib/tmpfiled.d path is very unlikely to change.
(In reply to Mike Gilbert from comment #9) > For what it's worth, I don't see any real problem with calling insinto and > doins directly. The /usr/lib/tmpfiled.d path is very unlikely to change. I've already tried that in the commit referenced by comment #2. However, see the response in comment #3. So, apparently we need to have unnecessary dependencies in order to comply with QA policy.
(In reply to Zac Medico from comment #10) IMHO, it doesn't make much of a difference from a QA point of view if /usr/lib/tmpfiles.d/ is hardcoded in tmpfiles.eclass or in the ebuild. Also, if tmpfiles.eclass requires dependencies that aren't necessary for some of its functionality, then maybe that functionality should be split off to a separate eclass (like tmpfiles-common.eclass or tmpfiles-utils.eclass)?
I guess we could use something like this to avoid hardcoding /usr/lib/tmpfiles.d: local tmpfilesdir tmpfilesdir=$($(tc-getPKG_CONFIG) --variable=tmpfilesdir systemd) : ${tmpfilesdir:=${EPREFIX}/usr/lib/tmpfiles.d} insinto "${tmpfilesdir#${EPREFIX}}" doins "${FILESDIR}"/portage-ccache.conf
(In reply to Ulrich Müller from comment #11) > Also, if tmpfiles.eclass requires dependencies that aren't necessary for > some of its functionality, then maybe that functionality should be split off > to a separate eclass (like tmpfiles-common.eclass or tmpfiles-utils.eclass)? Yeah, that would work too.
I looked into this a bit further, and the dependency is because of the tmpfiles_process function which can be called in pkg_postinst to immediately process the new tmpfiles.d entries. If you don't use that, the use of the eclass is a bit questionable possibly, but I'm open to other thoughts also.
Let's set TMPFILES_OPTIONAL=1 in the ebuild?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b45d31d6c0266c3104025a420a43fe26e58db59 commit 3b45d31d6c0266c3104025a420a43fe26e58db59 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-03-09 16:23:10 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-03-09 16:24:42 +0000 sys-apps/portage: set TMPFILES_OPTIONAL=1 Closes: https://bugs.gentoo.org/643386 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/portage/portage-2.3.99-r2.ebuild | 3 ++- sys-apps/portage/portage-3.0.12.ebuild | 1 + sys-apps/portage/portage-3.0.13.ebuild | 1 + sys-apps/portage/portage-3.0.16.ebuild | 1 + sys-apps/portage/portage-3.0.17.ebuild | 1 + sys-apps/portage/portage-9999.ebuild | 1 + 6 files changed, 7 insertions(+), 1 deletion(-)
