Only kill, pidof, and ps should be installed in /bin, and sysctl in /sbin. All the rest (for example, top) don't qualify as "essential binaries" and should therefore be installed in /usr/bin. This is a regression from 3.3.11-r1.
No compelling reason given why this is a regression.
Sure it is a regression. Read the FHS about what goes into /bin and what into /usr/bin. Also the upstream commit message explicitly recommends that distros should move the essential binaries to /bin and keep the rest in /usr/bin: "Distributions that would still like to split /bin from /usr/bin should actually move binaries such as `ps` and `kill` to /bin after the install of procps-ng is complete." https://gitlab.com/procps-ng/procps/commit/430b559ba2826f80dffa840622ae0fc744000b13 CCing QA.
we should move all programs into /usr/bin when feasible, but it's nothing to get all twisted over. de-escalating.
So... how do we move this bug forward? I already "fixed" it once without asking and that was reverted. Who gets let last word here?
I would have said QA (since it is a policy violation). However, Mike has removed QA from CC to "de-escalate". I hope this implies that maintainers will fix it in a timely manner?
(In reply to Mike Gilbert from comment #4) seeing as it's not a critical issue, it'll happen when it happens. attach a patch here if you want. we probably don't even need pidof in /, just ps & kill. (In reply to Ulrich Müller from comment #5) that's overstating things
(In reply to SpanKY from comment #6) That really does not answer my question; what's the difference between you committing when you feel like it, and me committing it now? And is your team in agreement with it?
Created attachment 416712 [details, diff] Move non-essential binaries back to /usr/bin Here's a patch.
(In reply to Mike Gilbert from comment #8) > Created attachment 416712 [details, diff] [details, diff] > Move non-essential binaries back to /usr/bin I think it should be /sbin/sysctl so you should keep the --sbindir="${EPREFIX}"/sbin econf option.
Sorry if I seem impatient; I just don't want to see this bug sit here for some indefinite amount of time. A decision needs to be made about where these files should live, and I think it should be made before users start running into problems. We have seen one instance of a program failing at runtime due to the move, and there will probably be a few more. It's not a critical problem, but would be simple to avoid it if you act swiftly to revert the change.
Created attachment 416714 [details, diff] Keep --sbindir Here's a new patch per ulm's feedback.
(In reply to Mike Gilbert from comment #7) you're not the maintainer. if Lars (or anyone else) has concerns/opinions, they can post them here, or chat on the team alias, or on irc. (In reply to Mike Gilbert from comment #8) looks fine, although i would pedantically put a / after the "${ED}"/bin/ (In reply to Ulrich Müller from comment #9) sysctl wasn't historically in / (i did a quick scan of the procps history and didn't see it, but i could be misremembering such an insignificant detail) and i don't think we want to move it. people haven't been complaining about it, and i don't think it qualifies as critical. tweaking things in /proc/sys/ is rarely (ever?) required to get /usr online. (In reply to Mike Gilbert from comment #10) i'm not seeing any critical timing issues here. if anything, the packages you allude to are broken. you should not be hardcoding any path in scripts (this is why we have $PATH), and i have no sympathy for when things break because someone did it wrong. the fact that these changes uncovered those errors is a service and you should take the time to fix those packages. moving files around in procps is merely masking that issue and is not the "fix" to unbreak those broken packages.
(In reply to SpanKY from comment #12) > (In reply to Ulrich Müller from comment #9) > > sysctl wasn't historically in / (i did a quick scan of the procps history > and didn't see it, but i could be misremembering such an insignificant > detail) and i don't think we want to move it. people haven't been > complaining about it, and i don't think it qualifies as critical. tweaking > things in /proc/sys/ is rarely (ever?) required to get /usr online. $ e-file /sbin/sysctl [I] sys-process/procps Available Versions: 3.3.11-r2 3.3.11 3.2.8_p11 3.3.8 3.2.8 3.3.4 3.3.9 3.3.10-r1 3.3.6 3.3.9-r2 [...] $ e-file /usr/sbin/sysctl [I] sys-process/procps Available Versions: 3.3.11-r1 [...] So it was always installed in /sbin except for the short lived 3.3.11-r1.
(In reply to SpanKY from comment #12) In the case of bug 565500, they are not hard-coding the path, they are detecting it at build time. It's generally a reasonable assumption that binaries will not randomly move around within a release on a Linux distro. If we were a more traditional binary distro, it would not be a problem at all. I don't really care if you are sympathetic to people "doing it wrong"; I do care that we are breaking things for no good reason. If there were some good reason for it, that would be another matter.
(In reply to Ulrich Müller from comment #13) > (In reply to SpanKY from comment #12) > > (In reply to Ulrich Müller from comment #9) > > > > sysctl wasn't historically in / (i did a quick scan of the procps history > > and didn't see it, but i could be misremembering such an insignificant > > detail) and i don't think we want to move it. people haven't been > > complaining about it, and i don't think it qualifies as critical. tweaking > > things in /proc/sys/ is rarely (ever?) required to get /usr online. > > So it was always installed in /sbin except for the short lived 3.3.11-r1. This is probably because the sbuild used to pass --exec-prefix="${EPREFIX}" to configure. The default sbindir is ${exec_prefix}/sbin.
(In reply to Ulrich Müller from comment #13) ok, i was looking at the things we were moving by hand rather than configure/make doing it for us. i still don't think it should move back. (In reply to Mike Gilbert from comment #14) no, detecting full paths at build time is broken. those packages need to be fixed to not be stupid. that procps broke them is immaterial and still a service well provided.
> (In reply to Mike Gilbert from comment #14) > > no, detecting full paths at build time is broken. those packages need to be > fixed to not be stupid. that procps broke them is immaterial and still a > service well provided. I disagree. I will leave it at that.
(In reply to Mike Gilbert from comment #17) so if someone locally has something in say /usr/local/bin (or any other thing in $PATH) and later cleans it up, he has to worry about broken packages ? that's fundamentally wrong.
Fair point, though I think that is a pretty rare occurrence.
(In reply to Mike Gilbert from comment #19) how about cross-compiling ? we specifically do not require nor want to require that the host system look exactly like the target. probing of paths will fail there as well.
Yup, that's a better example. Thanks.
I'm with Mike and Lars on this bug. There is nothing to do for procps; the packages that are hard coding paths (or detecting paths at build time and hard-coding them) are wrong and should be fixed.
Policy reference: https://devmanual.gentoo.org/general-concepts/filesystem/index.html
(In reply to William Hubbs from comment #22) orthogonal issues. while packages that hardcode paths (either in source directly or via build time detection) are broken, that doesn't preclude us from moving things out of /. it also makes the split-/usr question simpler as we have fewer places to track. (In reply to Ulrich Müller from comment #23) all of which are recommendations
(In reply to SpanKY from comment #24) > (In reply to William Hubbs from comment #22) > > orthogonal issues. while packages that hardcode paths (either in source > directly or via build time detection) are broken, that doesn't preclude us > from moving things out of /. it also makes the split-/usr question simpler > as we have fewer places to track. Actually, you are correct, we could very easily move all of procps out of / and be done with it. I didn't do it that way because we haven't officially decided to merge / into /usr, and because when I spoke with Lars about this, his position was we should put the binaries and libraries in /. I'll attach a patch that puts everything in /usr. This would actually create a much cleaner ebuild since upstream by default installs everything in /usr.
Created attachment 416818 [details, diff] procps-usr.patch This patch would make procps install everything in /usr. @vapier: Should we do this and be done with it?
@vapier: Actually thinking about it, I don't think we can do that without breaking systemd units.
It is quite common for systemd units to contain entries like this: [Service] ExecReload=/bin/kill -HUP $MAINPID I would like to request that you not force me to waste my time "fixing" these because you want to move kill to /usr/bin for no particular reason that I can see. Please just leave the darn command where it is; you can move it if/when we ever do the /usr merge and the /bin -> /usr/bin symlink is safely in place.
Ah, I missed comment 27; thank you for keeping us in mind there!
Also note that if you move sysctl to /usr/sbin then you may want to patch the sysctl.8 manpage which refers to /sbin/sysctl in a few places.
<QA hat> Fixed: - ps and kill into /bin - all other binaries into /usr - path in sysctl.8 updated accordingly </QA hat>
(In reply to Mike Gilbert from comment #28) those systemd units are broken. there's no reason to hardcode the path to kill. (In reply to Ulrich Müller from comment #31) just to re-iterate, there is/was no QA issue here. disagreeing with a move does not make it QA territory.
(In reply to SpanKY from comment #32) > just to re-iterate, there is/was no QA issue here. disagreeing with a move > does not make it QA territory. If you insist ... GLEP 48 outlines the procedure: "In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council." (Although from comment #3 I had concluded that you are fine with moving things back to /usr/bin.)
(In reply to SpanKY from comment #32) > (In reply to Mike Gilbert from comment #28) > > those systemd units are broken. there's no reason to hardcode the path to > kill. systemd units can only call absolute paths; upstream isn't going to change that. A possible alternative would be to do something like this: ExecReload=/usr/bin/env kill -HUP $MAINPID Which only works if nobody moves /usr/bin/env on me. It also means patching lots of unit files for very little actual benefit.
(In reply to Ulrich Müller from comment #33) which we already covered in comment #24, hence QA has no standing here. i'm not against the change which is why i didn't revert/re-open/WONTFIX. (In reply to Mike Gilbert from comment #34) considering systemd is big on "not forking", it seems weird they don't provide an option to handle sending a signal themselves
(In reply to SpanKY from comment #35) > considering systemd is big on "not forking", it seems weird they don't > provide an option to handle sending a signal themselves Yes, that does seem to be something that is missing. However, the systemd.service(5) man page sheds some light on why that feature has not been added. http://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecReload= > One additional, special environment variable is set: if known, $MAINPID is set to the main process of the daemon, and may be used for command lines like the following: > > /bin/kill -HUP $MAINPID > > Note however that reloading a daemon by sending a signal (as with the example line above) is usually not a good choice, because this is an asynchronous operation and hence not suitable to order reloads of multiple services against each other. It is strongly recommended to set ExecReload= to a command that not only triggers a configuration reload of the daemon, but also synchronously waits for it to complete.
