| Summary: | tmpfiles.eclass: virtual/tmpfiles dependency is not always needed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Zac Medico <zmedico> |
| Component: | Current packages | Assignee: | Gentoo systemd Team <systemd> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gyakovlev, mgorny, sam, williamh |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=774855 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 643386 | ||
|
Description
Zac Medico
2020-09-09 04:30:16 UTC
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(-) |
