| 1 |
On Thu, Nov 17, 2016 at 3:07 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> |
| 3 |
> Realistically, software should ensure the directories it needs at |
| 4 |
> runtime are created through their own code, but upstreams are lazy and |
| 5 |
> so they don't bother because, hey, we can have this tmpfiles.d *.conf |
| 6 |
> file to have the system do it for us! |
| 7 |
|
| 8 |
This isn't really being lazy. This is just not re-inventing the |
| 9 |
wheel. If there is a standard way to ensure that directories are set |
| 10 |
up correctly (especially if they're volatile, or you have a |
| 11 |
first-time-every-time scenario like a container) then why not use it? |
| 12 |
|
| 13 |
It certainly makes more sense than a bunch of shell code in a unit |
| 14 |
file (which then must be duplicated in an init.d script), or having |
| 15 |
the program run as root, create directories, and then drop privs. |
| 16 |
|
| 17 |
It was less of an issue when things were less volatile. However the |
| 18 |
trend in servers especially has been towards volatility. Every boot |
| 19 |
basically is the first boot. A lot more stuff ends up on a tmpfs as |
| 20 |
well. |
| 21 |
|
| 22 |
> In those cases, we'd need that rdepend. |
| 23 |
|
| 24 |
I tend to agree with this thinking. If the package needs these |
| 25 |
directories at runtime, and the tmpfiles.d config is the mechanism to |
| 26 |
create it, then the package has a runtime dependency on a program that |
| 27 |
will do what it says. |
| 28 |
|
| 29 |
That said, I'm not 100% on this as this is a bit of an unusual |
| 30 |
situation. This is generally boot-time configuration so you have a |
| 31 |
package run-time dependency on a package being there at boot time. It |
| 32 |
isn't exactly the typical sort of requirement. |
| 33 |
|
| 34 |
|
| 35 |
-- |
| 36 |
Rich |
Archives