1 |
On Tue, May 24, 2022 at 6:49 AM <karl@××××××××.se> wrote: |
2 |
> |
3 |
> Is there some hook to emerge I can use where I can attach some code to |
4 |
> run tests after each individual package when doing emerge @world ? |
5 |
> |
6 |
|
7 |
So, Portage has hooks, and that would work for any file being |
8 |
installed normally (so would config protection and that would be a |
9 |
much easier solution). |
10 |
|
11 |
There are a couple of problems though: |
12 |
1. The only package I'm aware of that directly touches /dev is |
13 |
static-dev (which I hadn't even heard of until you mentioned it). It |
14 |
uses a post-install hook to create device nodes, so there is no |
15 |
opportunity to inspect anything before /dev is modified. This isn't |
16 |
the normal way to install files, but of course it isn't installing |
17 |
normal files. |
18 |
2. I think it is very unlikely that a package is directly modifying |
19 |
/dev. It seems more likely that a package is installing some daemon |
20 |
that gets run as root and then it modifies /dev, maybe on your next |
21 |
boot. Obviously if you install something like udev you'd expect to |
22 |
end up with /dev getting modified when it runs. Again, there is |
23 |
nothing for a hook to detect. |
24 |
|
25 |
Having a backup (it is static after all), and something like a |
26 |
read-only mount might be your better solutions, if you really want a |
27 |
static dev, or maybe marking files as immutable or something. (You |
28 |
might want to test that - I am assuming you could still write to a |
29 |
device node on a read-only filesystem but it isn't like I've tried. I |
30 |
don't think there is anything special about /dev so you could just |
31 |
create a device node in some other read-only filesystem and test it |
32 |
out.) |
33 |
|
34 |
If you do find a random package touching /dev I think most here would |
35 |
be pretty interested, as that seems rather bizarre. |
36 |
|
37 |
-- |
38 |
Rich |