| Summary: | sys-apps/opentmpfiles-0.1.3: keywording for non-Linux systems | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> | ||||
| Component: | Keywording | Assignee: | William Hubbs <williamh> | ||||
| Status: | CONFIRMED --- | ||||||
| Severity: | normal | CC: | James_McMechan, kingjon3377, openrc, prefix, systemd | ||||
| Priority: | Normal | ||||||
| Version: | unspecified | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=644484 https://bugs.gentoo.org/show_bug.cgi?id=647752 |
||||||
| Whiteboard: | |||||||
| Package list: | Runtime testing required: | --- | |||||
| Attachments: |
|
||||||
@prefix, do you have an opinion of some kind? observation: sys-apps/opentmpfiles ebuild isn't prefix ready * QA Notice: the following files are outside of the prefix: * /bin * /bin/tmpfiles * ERROR: sys-apps/opentmpfiles-0.1.3::gentoo failed: * Aborting due to QA concerns: there are files installed outside the prefix That aside, we don't do daemons and stuff at the moment, and likely won't for the forseeable future. But ideally, we'd do everything in our offset, have runscripts work, etc. Just dropping this stuff when use prefix with some einfo or something would work, we do the same thing currently for doinitd iirc. Created attachment 516054 [details, diff]
patch for opentmpfiles-9999 to support Prefix
This patch adds Prefix support to opentmpfiles-9999 (git diff with renaming tmpfiles -> tmpfiles.in), without the need to change the opentmpfiles.ebuild - Makefile takes EPREFIX from environment if set.
However, packages providing tmpfiles.d/.conf files may need to be reverted to not add the EPREFIX to the Path part of the conf file - see comments in the patch.
Tested with app-portage/eix when EPREFIX was removed from eix.conf - with this warning to be fine for now:
$ tmpfiles --create
chown: changing ownership of '/tools/haubi/gentoo/test/var/cache/eix': Operation not permitted
William, could you please share your thoughts on the patch? All of the Prefix are affected when they want to install eix, which started to depend on opentmpfiles. I don't like this idea. We've already had to fix one mess resulting from Prefix people unconditionally prepending their prefix everywhere and now you're trying to repeat the same mistake. Yes, I get it. Mangling all the files is a lot of work, especially when many upstreams may ignore the problem. However, once you start prepending the prefix there's no way back, and mangling stuff to remove duplicate prefix is even more insane. Prepending the prefix is not the logical thing people can expect. That said, I have no clue how Prefix is going to handle the idea that /run is supposed to be a single top-level filesystem. (In reply to Michał Górny from comment #0) > However, I'm not really sure how we should handle Prefix. I see two > possibilities here: > > 1. We ensure that the tmpfiles.d rules are properly prefixified -- i.e. sed > ${EPREFIX} into the files or alike. In this case, we may also want to pass > --prefix= to opentmpfiles (providing the option if it's not supported yet) > to restrict the applied rules to those starting with ${EPREFIX} only (i.e. > ignore rules touching directories outside the Prefix). > > 2. We implicitly 'prefixify' rules via using the --root= option. In this > case we don't need to alter the paths (although it could end up being > confusing if people actually do that), and we don't need to restrict them. > Worst case, useless /run and /var/run subdirectories would be created inside > the Prefix. I prefer the align the behavior of opentmpfiles to that of openrc, to treat directories as real paths. It is basically Option 1. At the same time, providing a runtime Prefix variable like ${RC_PREFIX} for openrc scripts can avoid `sed`-ing every files in tmpfiles.d. That said, if opentmpfiles offers both --prefix and --root. The '--root' option speaks out itself to prepending every paths. In that case, we can support both Options 1. and 2. > So it pretty much boils down to a more fundamental question: how does Prefix > want to handle runtime directories, e.g. directories used for pidfiles, > locks...? Most of the host systems Prefix runs on do not offer /run. Therefore, that directory for Prefix should go to $EPREFIX/run. (In reply to Benda Xu from comment #6) > (In reply to Michał Górny from comment #0) > > > However, I'm not really sure how we should handle Prefix. I see two > > possibilities here: > > > > 1. We ensure that the tmpfiles.d rules are properly prefixified -- i.e. sed > > ${EPREFIX} into the files or alike. In this case, we may also want to pass > > --prefix= to opentmpfiles (providing the option if it's not supported yet) > > to restrict the applied rules to those starting with ${EPREFIX} only (i.e. > > ignore rules touching directories outside the Prefix). > > > > 2. We implicitly 'prefixify' rules via using the --root= option. In this > > case we don't need to alter the paths (although it could end up being > > confusing if people actually do that), and we don't need to restrict them. > > Worst case, useless /run and /var/run subdirectories would be created inside > > the Prefix. > > I prefer the align the behavior of opentmpfiles to that of openrc, to treat > directories as real paths. It is basically Option 1. > > At the same time, providing a runtime Prefix variable like ${RC_PREFIX} for > openrc scripts can avoid `sed`-ing every files in tmpfiles.d. For the record. ${RC_PREFIX} is not an option here, because the files should also work with systemd-tmpfiles. Also we should take into consideration that upstreams may be generating tmpfiles.d via configure scripts, respecting --prefix. In that case, the files will contain EPREFIX already. I expect sys-apps/opentmpfiles-0.1.3-r1
was trying to fix this problem however it has a double prefix problem
towards the end if failed with
install -m 0755 tmpfiles /data/gentoo/var/tmp/portage/sys-apps/opentmpfiles-0.1.3-r1/image/data/gentoo//data/gentoo/bin
Then dropping out due to a 'QA Notice: data/gentoo///data/gentoo/ double prefix'
Now my understanding of the prefix ebuild magic is limited it looks on first guess to be that either 'hprefixify tmpfiles' or 'emake DESTDIR="${ED}" install' should be present, not both?
I tried it with 'emake install' instead and it seems to build and install
I do not know how to test this package however
so what's the conclusion here? opentmpfiles doesn't work, the patch isn't cool Do we /need/ opentmpfiles on Prefix at all? |
Would you mind me asking our Prefix team to look for possibility of using opentmpfiles for non-Linux systems? The tmpfiles.eclass pull request [1] can be used as a base for review/testing. Our FreeBSD guru has already tested and confirmed that opentmpfiles work fine for {amd64,x86}-fbsd. I don't think it would have any natural trouble on other non-Linux systems. However, I'm not really sure how we should handle Prefix. I see two possibilities here: 1. We ensure that the tmpfiles.d rules are properly prefixified -- i.e. sed ${EPREFIX} into the files or alike. In this case, we may also want to pass --prefix= to opentmpfiles (providing the option if it's not supported yet) to restrict the applied rules to those starting with ${EPREFIX} only (i.e. ignore rules touching directories outside the Prefix). 2. We implicitly 'prefixify' rules via using the --root= option. In this case we don't need to alter the paths (although it could end up being confusing if people actually do that), and we don't need to restrict them. Worst case, useless /run and /var/run subdirectories would be created inside the Prefix. So it pretty much boils down to a more fundamental question: how does Prefix want to handle runtime directories, e.g. directories used for pidfiles, locks...? [1]:https://github.com/gentoo/gentoo/pull/4526