If system didn't migrate to /run, then net.* services stop working if they are using dhcpcd. Reproducible: Always Steps to Reproduce: 1. make sure /var/run is not a symlink to /run (make it directory, for example, on tmpfs) 2. start net.* service which uses dhcpcd 3. stop this service 4. start it again Actual Results: service start fails with message that dhcpcd is already running Expected Results: service should start successfully dhcpcd breaks FSH-compliant systems which didn't migrate to /run. The migration to /run is supposed to be FSH-compatible, isn't it? In case /var/run is symlink to /run, using /var/run would work fine for run-migrated systems. In case /var/run is not a symlink, it breaks non-migrated systems.
Created attachment 374516 [details, diff] dhcpcd-6.2.0-r1.ebuild.patch patch to revert it back to using /var/run
Comment on attachment 374516 [details, diff] dhcpcd-6.2.0-r1.ebuild.patch We couldn't possibly go back (bug #332633).
(In reply to i.Dark_Templar from comment #0) > dhcpcd breaks FSH-compliant systems which didn't migrate to /run. The > migration to /run is supposed to be FSH-compatible, isn't it? In case > /var/run is symlink to /run, using /var/run would work fine for run-migrated > systems. In case /var/run is not a symlink, it breaks non-migrated systems. Gentoo is not in the business of creating FHS compliant distros, last I checked.
if you have /run, then /var/run should be a symlink to it. there isn't a lot (if any at all) of value in us trying to support both now.
Created attachment 374584 [details, diff] dhcpcd-6.2.0-r1.ebuild.patch
(In reply to Jeroen Roovers from comment #3) > Gentoo is not in the business of creating FHS compliant distros, last I > checked. (In reply to SpanKY from comment #4) > if you have /run, then /var/run should be a symlink to it. there isn't a > lot (if any at all) of value in us trying to support both now. Then I choose /var/run. It's a standard. /run is forced on me by openrc s#&t. And how does using /var/run returns bug #332633? It is created runtime, I checked it. As SpanKY wrote, if you have /run, then you have /var/run as symlink to /run. In this case using /var/run will do no harm. But if /var/run is not a symlink, then it just breaks everything. Are you breaking Gentoo on purpose? I'd like to have it at least as USE-flag. I called it "fhs" which stands for "Filesystem Hierarchy Standard compliant". And you can break your own installation as much as you want.
sorry, but not a chance. just use /run already. if you dislike this, then maybe try FreeBSD.
(In reply to i.Dark_Templar from comment #6) > (In reply to Jeroen Roovers from comment #3) > > Gentoo is not in the business of creating FHS compliant distros, last I > > checked. > > (In reply to SpanKY from comment #4) > > if you have /run, then /var/run should be a symlink to it. there isn't a > > lot (if any at all) of value in us trying to support both now. > > Then I choose /var/run. It's a standard. /run is forced on me by openrc s#&t. /run is currently queued for consideration into FHS 3.0, and it's already used by Debian, so it's not something "forced" by OpenRC. Refer to this bug, which has a rather detailed set of comments on the purpose of /run vs /var/run: https://bugs.linuxfoundation.org/show_bug.cgi?id=718 Here's the master tracker bug for FHS 3.0: https://bugs.linuxfoundation.org/show_bug.cgi?id=758 So, just consider us preparing for the eventual implementation of FHS 3.0 -- Gentoo is a bleeding edge distribution, after all :)
