Summary: | sys-apps/portage: unnecessary opentmpfiles dependency inherited from tmpfiles.eclass | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | nobody <noreply> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | h.mth, jstein, mgorny, qa, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=490676 https://bugs.gentoo.org/show_bug.cgi?id=774855 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 740600, 741348 | ||
Bug Blocks: |
Description
nobody
2018-01-04 10:39:59 UTC
(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(-) |