Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 617580 - sys-apps/opentmpfiles-0.1.3: keywording for non-Linux systems
Summary: sys-apps/opentmpfiles-0.1.3: keywording for non-Linux systems
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Keywording (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: William Hubbs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-05 14:06 UTC by Michał Górny
Modified: 2021-01-06 13:52 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for opentmpfiles-9999 to support Prefix (0001-Support-installing-into-EPREFIX.patch,11.81 KB, patch)
2018-01-23 15:45 UTC, Michael Haubenwallner
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-05-05 14:06:44 UTC
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
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-05-16 16:10:17 UTC
@prefix, do you have an opinion of some kind?
Comment 2 Fabian Groffen gentoo-dev 2017-05-16 19:47:36 UTC
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.
Comment 3 Michael Haubenwallner gentoo-dev 2018-01-23 15:45:55 UTC
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
Comment 4 Benda Xu gentoo-dev 2018-01-31 20:38:57 UTC
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.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-01-31 21:10:23 UTC
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.
Comment 6 Benda Xu gentoo-dev 2018-01-31 21:14:50 UTC
(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.
Comment 7 Benda Xu gentoo-dev 2018-01-31 21:29:25 UTC
(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.
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-01-31 21:31:50 UTC
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.
Comment 9 James McMechan 2018-08-31 06:45:03 UTC
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
Comment 10 Fabian Groffen gentoo-dev 2021-01-06 13:52:46 UTC
so what's the conclusion here?  opentmpfiles doesn't work, the patch isn't cool

Do we /need/ opentmpfiles on Prefix at all?