| View previous topic :: View next topic |
| Author |
Message |
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
 Posted: Fri Sep 28, 2018 12:18 pm Post subject: |
 |
|
Thanks everyone, I have changed the title of the thread as it became apparent to me that it was opentmpfiles which I wanted to avoid and that I have tmpfiles already as part of openrc-0.13.11.
Adding virtual/tmpfiles-0 to package.provided works for me.
Sorry for any confusion caused by my incorrect thread title and initial post information 
Thanks for explaining tmpfiles and why it is probably a good idea for me to retain it  |
|
| Back to top |
|
 |
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Fri Sep 28, 2018 12:58 pm Post subject: |
|
|
| Anon-E-moose wrote: | Upstream is not forcing us to do this, it's Hubbs insane desire to make openrc look like systemd.
Since there are holdouts not wanting a systemd only distro, he's decided to slowly destroy it by making it look like the warmed over coprophilic pile called systemd.
That's all on Hubbs and should be a reason for his dismissal from power in gentoo. |
I do not know Hubbs motivation - but sadly the outcome appears to be some fairly fundamental packages like openrc are suffering ... it might be that the only practical way to run a system with openrc for most people in future is by supporting more and more mechanisms like those provided as part of systemd which system components/applications rely on. For me at present openrc-0.13.11 does what I need but having this package in a local overlay rather than using the in tree stable version is a worry ... but some of the changes going on with openrc at the time made little sense to me. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Sep 28, 2018 2:27 pm Post subject: |
|
|
One other thing is needed to emulate the latest tmpfiles on older openrc
| Code: | | ln -s /lib/rc/sh/tmpfiles.sh /bin/tmpfiles |
Either be root or sudo to do the above.
That's because tmpfiles_process in tmpfiles.eclass calls it to run the /usr/lib/tmpfiles.d/*.conf files for whatever is put there.
I just noticed that I didn't have a /run/sudo directory, and that hasn't stopped sudo from running.
But the change above 100% mirrors what the latest opentmpfiles does.
---
These are the files that call tmpfiles.eclass (right now)
app-admin/sudo
app-admin/puppetserver
app-emulation/virtualbox
app-metrics/collectd
app-portage/eix
dev-db/mysql-init-scripts
mail-filter/policyd-weight
net-ftp/proftpd
net-im/coturn
net-misc/connman
net-misc/quagga
net-misc/gerbera
net-p2p/resilio-sync
sys-apps/logwatch
www-servers/apache
x11-wm/xpra
but out of those these are the only files in /usr/lib/tmpfiles.d
cyrus-sasl.conf
eix.conf
man-db.conf
named.conf
portage-ccache.conf
revdep-rebuild.conf
samba.conf
sudo.conf
I checked what was running vs what would have happened if I had had the link done earlier and
I had to run sudo.conf and named.conf (though they were fine with the old permissions)
To manually run (and do what tmpfiles_process from eclass does by way of the ebuild)
| Code: | | tmpfiles --create /usr/lib/tmpfiles.d/<name>.conf |
In the case of sudo it creates a directory and a directory w/timestamp under it (systemd crapola) but sudo had worked just fine without it (I use it daily)
In the case of named it changed the directory permissions from 770 root name to 755 named named. But again it's been working just fine for me the old way.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Last edited by Anon-E-moose on Fri Sep 28, 2018 5:04 pm; edited 1 time in total |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Fri Sep 28, 2018 4:00 pm Post subject: |
|
|
| Anon-E-moose wrote: | ETA2: I did look at the difference between what's in openrc-0.13 and opentmpfile-0.1.3 and the init.d files differ in where the tmpfiles shell script is called from, but the options passed are exactly the same, other than location of shell script.
Opentmpfiles puts the tmpfiles shell script in /bin instead of /lib/rc/sh/ which is stupid, AFAIC, as it's not something that should be used indiscriminately, which it might be if left in /bin.
The tmpfiles shell script has been changed, mostly to add new options, for dry-run, etc. but overall it does the same things as tmpfiles.sh from <openrc-0.23. |
Thank you for your research. I have updated my ebuild accordingly. I intend to research all these differences between the tarballs that you kindly linked to, but it will probably take months, squeezing it in a bit at a time. |
|
| Back to top |
|
|
engineermdr
Apprentice
Joined: 08 Nov 2003
Posts: 295
Location: Altoona, WI, USA
|
| Posted: Fri Sep 28, 2018 8:51 pm Post subject: |
|
|
| Thanks everyone! This topic has been very useful to me as well. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Sep 29, 2018 10:57 am Post subject: |
|
|
| Hu wrote: | | Given those choices, supporting tmpfiles is the path of least resistance. |
Hu ... missed this yesterday. I thought the argument was that we accept systemd into the tree as "gentoo is about choice", and that such choices would happily co-exist. When the results of that "choice" is laid bare we are prompted to accept the current state of affairs, as though it wasn't obvious from the outset that such "choice" would negatively effect those not choosing systemd. At the time, anyone voicing an objection was labelled anti-choice, and the substantive question of what that choice would inevitably mean was swept aside, because it simply didn't serve the interests of those promoting its inclusion/adoption. All of this was clear as day, but there wasn't the political will to do anything to resist this deception, and to preserve some semblance of "community". That is gentoo's failure, not upstream's ... and so after the fact we can't pretend that this state of affairs wasn't the result of our actions (including that of following "the path of least resistance") ... we didn't stumble blindly into this situation, we were active participants (some more than others). So, I reject the idea that this is some sort of accident that we must now make the best of, that is little more than cover for those who actively brought this about (again, some more than others), otherwise all we have here is peace of the boiled frog front.
best ... khay |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Sep 29, 2018 11:34 am Post subject: |
|
|
I know I was on openrc-0.9.8.4 for a couple of years and it didn't have tmpfiles at all, I also think that was before the /usr "merge"
I went from there to openrc-0.11.5/6 and tmpfiles was in that version. So not sure exactly when it was introduced but between those 2 versions
The system did work well without tmpfiles, I think they just used whatever package defaults there were for dir/file permissions.
Edit to add: From the 0.13.11 ebuild
| Code: | # termencoding was added in 0.2.1 and needed in boot
has_version ">=sys-apps/openrc-0.2.1" || add_boot_init termencoding
# swapfiles was added in 0.9.9 and needed in boot (february 2012)
has_version ">=sys-apps/openrc-0.9.9" || add_boot_init swapfiles
if ! has_version ">=sys-apps/openrc-0.11"; then
add_boot_init sysfs sysinit
fi
if ! has_version ">=sys-apps/openrc-0.11.3" ; then
migrate_udev_mount_script
add_boot_init tmpfiles.setup boot
fi
# these were added in 0.12.
if ! has_version ">=sys-apps/openrc-0.12"; then
add_boot_init loopback
add_boot_init tmpfiles.dev sysinit |
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Sat Sep 29, 2018 4:11 pm Post subject: |
|
|
khayyam: for this thread, I am mostly ignoring how we got into the state that systemd has encroached as far as it has, and consequently ignoring who is at fault for the situation. I am looking at the practical consequences to non-systemd users, which is what I laid out above. Their choices are:- Cease using programs that develop a systemd dependency.
- Accept reduced, possibly severely reduced, functionality in those programs when the program tries to use systemd and cannot, because it is not installed. In extreme cases, the program may be completely unusable when systemd is absent.
- Patch those programs not to depend on systemd.
- Motivate the authors of those programs (e.g. GNOME) to make systemd optional.
- Emulate the systemd functionality that those programs now depend on.
For the specific situation of tmpfiles, the systemd solution is ugly, but relatively effective at solving the stated problem (the need for specific directories to effectively survive reboot, despite being stored in a tmpfs) and relatively easy to emulate on non-systemd systems. Other systemd features, such as its replacement for service management and the bundled in sandboxing, are far more invasive and may require a different answer. For example, it is currently accepted wisdom that services on a non-systemd system should be handled through an initscript (option 3 or option 4, depending on whether upstream maintains the script or the distribution maintains it), rather than having a service responsible for reading and executing systemd unit files (which would be option 5). |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Sat Sep 29, 2018 4:14 pm Post subject: |
|
|
| Hu wrote: | | Motivate the authors of those programs (e.g. GNOME) to make systemd optional. |
This is already the case. And it is done through elogind, which is a standalone logind implementation (see your point 5). Alas, some people prefer to run in circles rather than making a positive contribution, e.g. as a follow-up to https://forums.gentoo.org/viewtopic-p-8243122.html#8243122. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sat Sep 29, 2018 5:00 pm Post subject: |
|
|
| Hu wrote: | 3. Patch those programs not to depend on systemd.
4. Motivate the authors of those programs (e.g. GNOME) to make systemd optional. |
It is disconcerting how many seemingly non-Gnome programs now use the tmpfiles.eclass (Anon-E-moose's post). I presume it is due to upstream, which is why I find it disconcerting. I wonder how difficult it would be to port sudo from BSD. And there does appear to be at least one Linux port of OpenBSD's doas. But maybe the effort wouldn't be worth the benefit.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Sep 29, 2018 5:12 pm Post subject: |
|
|
Tmpfiles.eclass in and of itself isn't bad, though it hardcodes virtual/tmpfiles and that only looks at 2 choices systemd (sigh) and opentmpfile (which only looks at openrc >0.22) (sigh again)
Actually with a little modification, opentmpfile would work with all versions of openrc. It's not terribly difficult.
But not worth the effort to file a bug, go and forth with someone like hubbs and then have it rejected anyway.
Edit to add: I suppose a patch to openrc <0.23 would work then opentmpfile would be installed.
I just don't understand the mindset of people like hubbs who keep destroying things that work and try and make things like openrc look like systemd.
They don't do the same thing and if one looks at many ebuilds they are have an if-else for systemd/openrc, so it's not like it's forced to be one way.
ETA2: something like copying openrc-0.13.11.ebuild to openrc-1.13.11-r1.ebuild and applying this patch would probably work (off the top of my head - NOT TESTED)
| Code: | $ diff -u openrc-0.13.11.ebuild openrc-1.13.11-r1.ebuild
--- openrc-0.13.11.ebuild 2015-02-26 13:01:17.000000000 -0600
+++ openrc-1.13.11-r1.ebuild 2018-09-29 12:49:10.748413189 -0500
@@ -210,13 +210,13 @@
if ! has_version ">=sys-apps/openrc-0.11.3" ; then
migrate_udev_mount_script
- add_boot_init tmpfiles.setup boot
+ rm -f /etc/runlevels/boot/tmpfiles.setup
fi
# these were added in 0.12.
if ! has_version ">=sys-apps/openrc-0.12"; then
add_boot_init loopback
- add_boot_init tmpfiles.dev sysinit
+ rm -f /etc/runlevels/sysinit/tmpfiles.dev
# ensure existing /etc/conf.d/net is not removed
# undoes the hack to get around CONFIG_PROTECT in openrc-0.11.8 and earlier |
It does leave /lib/rc/sh/tmpfiles.sh where it is, but it won't be used so no big deal
and it would allow opentmpfile to be installed and run (no need for virtual/tmpfile in package.provided)
Several ways (choose your poison) 
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Sep 29, 2018 6:47 pm Post subject: |
|
|
| Hu wrote: | | khayyam: for this thread, I am mostly ignoring how we got into the state that systemd has encroached as far as it has, and consequently ignoring who is at fault for the situation. I am looking at the practical consequences to non-systemd users, which is what I laid out above. |
Hu ... which is to cast it as a technical problem, when it is in fact a socio-political problem.
best ... khay |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sat Sep 29, 2018 9:53 pm Post subject: |
|
|
| Anon-E-moose wrote: | | Tmpfiles.eclass in and of itself isn't bad, though it hardcodes virtual/tmpfiles and that only looks at 2 choices systemd (sigh) and opentmpfile (which only looks at openrc >0.22) (sigh again) |
The description of opentmpfiles indicates a "utility to process systemd-style tmpfiles.d files." So does that not mean virtual/tmpfiles must support "systemd-style tmpfiles.d files"? I personally do not want systemd style anything in my environment.
| Anon-E-moose wrote: | | Several ways (choose your poison) :lol: |
Unfortunately I have never been employed such that I could justifiably work on it during business hours, and playing Whack-A-Systemd is starting to take too much manual effort. I was already on openrc-0.28 by the time I found out about some of the changes and haven't made the time to downgrade (and be prepared to deal with breakage).
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Sep 29, 2018 10:35 pm Post subject: |
|
|
As I said earlier I've run without the .conf files being processed ala systemd, most software takes a reasonable default for directory ownership and permissions.
But in looking at even old openrc tmpfiles has been part of openrc going back to 0.11 IIRC, and it's followed the systemd way for a while, so even without it being acknowledge it's been there. It's just that with breaking it out into a separate package, it's gotten visible.
This is from tmpfiles.sh which came from openrc-0.13.11 that I run.
| Code: | # This instance is a pure-POSIX sh version, written by Robin H Johnson
# <robbat2@gentoo.org>, based on the Arch Linux version as of 2012/01/01:
# http://projects.archlinux.org/initscripts.git/tree/arch-tmpfiles
#
# See the tmpfiles.d manpage as well:
# http://0pointer.de/public/systemd-man/tmpfiles.d.html
# This script should match the manpage as of 2012/03/12 |
Is it necessary? No, I use the older version and the latest sudo and named still ran fine, even though directories weren't being created ala systemd way.
Both new sudo and named call /bin/tmpfiles, which the older versions of openrc didn't have, they used /lib/rc/sh/tmpfiles.sh, so .conf files didn't get run.
New eix .conf didn't get called either but /var/cache/eix directory had already had the correct ownership/permissions from previous installs.
I don't think there would be much breakage with downgrading, but since I've not upgraded and then downgraded, take my opinion with a grain of salt.
I do know that with a reasonable amount of system knowledge you wouldn't be left with an unusable system.
Basically, put virtual/tmpfiles in package.provided, depclean opentmpfile and set a limit on openrc <0.23
Going forward from here, it's just play it by ear, maybe the openrc devs will quit mucking with it and things like opentmpfile, but who knows.
Edit to add:
| Code: | $ equery d openrc
* These packages depend on openrc:
net-misc/netifrc-0.2.2 (>=sys-apps/openrc-0.12)
virtual/service-manager-0 (!prefix ? sys-apps/openrc) |
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sat Sep 29, 2018 11:31 pm Post subject: |
|
|
| Code: | tony@MSI ~ $ equery d openrc
* These packages depend on openrc:
media-tv/sageclient-bin-9.1.9.514-r4 (sys-apps/openrc)
media-tv/sageserver-bin-9.1.9.514-r2 (sys-apps/openrc)
net-misc/netifrc-0.2.2 (sys-apps/openrc)
virtual/service-manager-0 (!prefix ? sys-apps/openrc)
virtual/tmpfiles-10-r2 (<sys-apps/openrc-0.23)
|
The first two are from my private overlay and as indicated above, I've modified virtual/tmpfiles in that overlay.
Regarding sudo, I used meld to view the changes pre- and post- requiring tmpfiles but saw nothing indicating anything had changed. Why would tmpfiles be needed? Does sudo run during boot or sysinit? I don't see that. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Sep 30, 2018 7:38 pm Post subject: |
|
|
| Anon-E-moose wrote: | | when one is using an older openrc that supports tmpfiles |
I was surprised to hear that openrc-0.13 already had tmpfiles support. (Also from the topic I had guessed that this is not the case).
But I checked and you are right: tmpfiles support exists since openrc-0.11.
In this case, of course, package.provided has no technical issues and does not cause silent breakage (except perhaps due to some bugs in the early tmpfile implementation; I did not check now when these bugs have been fixed.) Of course with freezing the openrc version you also freeze the tmpfiles version unless you manually update from opentmpfiles. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sun Sep 30, 2018 8:23 pm Post subject: |
|
|
| Anon-E-moose wrote: | | But in looking at even old openrc tmpfiles has been part of openrc going back to 0.11 IIRC, and it's followed the systemd way for a while, so even without it being acknowledge it's been there. It's just that with breaking it out into a separate package, it's gotten visible. |
Exactly. So the "systemd style tmpfiles" are going to be there, regardless. So I have to ask myself, what am I gaining by fighting opentmpfiles? My interest in downgrading openrc predated this information, which seems to make less worth the effort.
| Anon-E-moose wrote: | | Is it necessary? No, I use the older version and the latest sudo and named still ran fine, even though directories weren't being created ala systemd way. |
Despite that, sudo theoretically expects the support to exist, does it not?
| Anon-E-moose wrote: | Both new sudo and named call /bin/tmpfiles, which the older versions of openrc didn't have, they used /lib/rc/sh/tmpfiles.sh, so .conf files didn't get run.
New eix .conf didn't get called either but /var/cache/eix directory had already had the correct ownership/permissions from previous installs. |
Is "optntmpfiles / systemd tyle tmpfiles" support optional without an option to disable it? I think I'm just getting more confused about what opentmpfiles supposedly does if applications that require it don't actually need it but don't allow for it to not be excluded. Such as "USE=-systemd" -> "systemd support is not necessary, so I don't required virtual/tmpfiles."
| Anon-E-moose wrote: | I don't think there would be much breakage with downgrading, but since I've not upgraded and then downgraded, take my opinion with a grain of salt.
I do know that with a reasonable amount of system knowledge you wouldn't be left with an unusable system.
Basically, put virtual/tmpfiles in package.provided, depclean opentmpfile and set a limit on openrc <0.23 |
I don't expect any problems, but given what it is, I presume that it could fail to boot. So I need to make sure my boot USB stick is still around / working. I had also planned to attempt it in a virtual environment. Mainly it's just not something I think of when I'm not busy with other stuff. Then I read something and remember, "Oh yeah, I was going to try that."
| Anon-E-moose wrote: | | Going forward from here, it's just play it by ear, maybe the openrc devs will quit mucking with it and things like opentmpfile, but who knows. |
The "play it by ear" part is my primary concern about the effort required to "fight it." Some of this is outside of my comfort zone. I recently had to fix the openrc-0.28 ebuild because "path_exists" was no longer supported. Fortunately newer ebuilds had the correction.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Sep 30, 2018 8:53 pm Post subject: |
|
|
I'll try and clarify and summarize with this post.
You don't really gain anything by fighting opentmpfile, if you're running a version of >=openrc-0.23,
whether you lock openrc at a particular version, just keep up with it as new versions roll along or downgrade it's up to you.
Downgrading doesn't buy you anything other than perhaps some peace of mind about the direction of openrc, but it requires a small amount of work.
If running a version of <openrc-0.23
These things need doing:
1. put virtual/tmpfiles in package.provided OR modify virtual/tmpfiles ala Tony's post from earlier OR modify opentmpfile to allow it to be installed with <=openrc-0.23
(last choice requires removing /etc/runlevels/sysinit/tmpfiles.dev and /etc/runlevels/boot/tmpfiles.setup, as opentmpfile will put new ones down,
along with modifying opentmpfile ebuild to remove "!<sys-apps/openrc-0.23" from RDEPEND)
2. if using 1st or 2nd choice from 1, then do this "ln -s /lib/rc/sh/tmpfiles.sh /bin/tmpfiles"
(effectively you're doing the same as opentmpfile and newer packages that call tmpfiles will work as well as older ones that call tmpfiles.sh)
That's the long and short of it. Pick your poison.
Edit to add:
as with any package that's locked at a particular version, when changes come along in the future,
extra work may be necessary to make the locked package compatible.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sun Sep 30, 2018 9:35 pm Post subject: |
|
|
Thanks for the feedback, I'll give it some thought. Maybe if things really go south, the path forward will reveal itself.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
