Consumers of tmpfiles.eclass do not necessarily need virtual/tmpfiles. For example, sys-apps/portage happens to install a tmpfiles.d config for bug 490676, but the only reason is to prevent systemd from deleting ccache files. This means that tmpfiles.eclass introduces an unnecessary opentmpfiles dependency whenever systemd is not installed. This unnecessary dependency can be frowned upon by people that are trying to eliminate unnecessary dependencies in order to minimize space consumption.
How many people are there, exactly? How many space savings are we talking about? How many packages exactly need that? Are we talking about gains for stage3? Or is it just a few complainers-about-everything that use busybox to boot their systems? It might be better to just let them use package.provided and avoid the added complexity for everyone.
(In reply to Michał Górny from comment #1) > How many people are there, exactly? How many space savings are we talking > about? How many packages exactly need that? Are we talking about gains for > stage3? Well, right now opentmpfiles is pretty small and has no dependencies. But who knows what the future may bring?
(In reply to Michał Górny from comment #1) > Or is it just a few complainers-about-everything that use busybox to boot > their systems? The issue is proportional to the size of opentmpfiles and its dependencies. > It might be better to just let them use package.provided and > avoid the added complexity for everyone. Hmm, I don't like package.provided much.
(In reply to Zac Medico from comment #2) > (In reply to Michał Górny from comment #1) > > How many people are there, exactly? How many space savings are we talking > > about? How many packages exactly need that? Are we talking about gains for > > stage3? > > Well, right now opentmpfiles is pretty small and has no dependencies. But > who knows what the future may bring? Are you suggesting that a tool to create temporary directories will include a dependency on LLVM in the future, so that it could compile tmpfiles.d into machine code?
If you promise that opentmpfiles will remain small as it is now, then that's good enough for me.
I would be fine with introducing a global variable to disable the dependency.
The idea of splitting the dotmpfiles function into separate tmpfiles-common.eclass or tmpfiles-utils.eclass as suggested in bug 643386 comment 11 sounds reasonable to me.
Resolved by https://bugs.gentoo.org/774855#c3?
Indeed. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e4f0c0765f07696ed3b10be96a54a4a6810ac46 commit 6e4f0c0765f07696ed3b10be96a54a4a6810ac46 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-03-08 19:35:45 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-03-08 22:29:42 +0000 tmpfiles.eclass: introduce TMPFILES_OPTIONAL variable This allows the automatic dependency on virtual/tmpfiles to be disabled. Bug: https://bugs.gentoo.org/774855 Signed-off-by: Mike Gilbert <floppym@gentoo.org> Acked-by: David Seifert <soap@gentoo.org> eclass/tmpfiles.eclass | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
