Dear package maintainers,
please do not mess with preexisting files in /dev.
I have static /dev and that suit me well for quite a few systems that
has a static environment, especially system that are intended to run
for a long time and where I tend to minimize the number of running
processes, every running process is something that can go wrong.
Their /dev/ files are set up for their intended use, and I don't want surprises there.
When upgrading it isn't easy to see what package that did
something to /dev so it isn't easy to bug the guilty party.
If sys-fs/static-dev is installed, please do not touch /dev,
if you want you can leave suggestions in some file.
On Mon, May 23, 2022 at 5:39 AM <karl@aspodata.se> wrote:...
Dear package maintainers,
please do not mess with preexisting files in /dev.
If you can identify specific packages that have caused you problems,
we can probably resolve them.
Is there some hook to emerge I can use where I can attach some code to
run tests after each individual package when doing emerge @world ?
On Tue, May 24, 2022 at 6:49 AM <karl@aspodata.se> wrote:
Is there some hook to emerge I can use where I can attach some codeto
run tests after each individual package when doing emerge @world ?
So, Portage has hooks, and that would work for any file being
installed normally (so would config protection and that would be a
much easier solution).
There are a couple of problems though:
1. The only package I'm aware of that directly touches /dev is
static-dev (which I hadn't even heard of until you mentioned it). It
uses a post-install hook to create device nodes, so there is no
opportunity to inspect anything before /dev is modified. This isn't
the normal way to install files, but of course it isn't installing
normal files.
2. I think it is very unlikely that a package is directly modifying
/dev. It seems more likely that a package is installing some daemon
that gets run as root and then it modifies /dev, maybe on your next
boot. Obviously if you install something like udev you'd expect to
end up with /dev getting modified when it runs. Again, there is
nothing for a hook to detect.
Having a backup (it is static after all), and something like a
read-only mount might be your better solutions, if you really want a
static dev, or maybe marking files as immutable or something. (You
might want to test that - I am assuming you could still write to a
device node on a read-only filesystem but it isn't like I've tried. I
don't think there is anything special about /dev so you could just
create a device node in some other read-only filesystem and test it
out.)
If you do find a random package touching /dev I think most here would
be pretty interested, as that seems rather bizarre.
--
Rich
As a long time static /dev user the only thing I've noticed updates making
a mess of is /dev/snd. I've not traced that, I know what it is and how to
fix it. Its faster to fix it now and again that it is to establish the root cause.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (3 / 13) |
Uptime: | 98:46:16 |
Calls: | 9,680 |
Calls today: | 1 |
Files: | 13,725 |
Messages: | 6,174,632 |