5

I'm writing a local program to be called by a udev IMPORT{program} rule. Normally, I'd install local software in /usr/local, but these udev rules are run when block devices appear. So they're running long before /usr is necessarily mounted.

I believe I'll also have to configure this to be copied to initramfs (which is easily done with /etc/initramfs-tools/hooks/). Normally, it seems, things use the same path on initramfs as on the root filesystem. (edit: it appears I don't actually have to add it to initramfs, the events are re-triggered after rootfs is mounted)

/etc is version controlled, so binaries there are best avoided.

I'm thinking my best bet may just be to install this in /lib/udev, under a file name starting with local- to avoid clashing with any future files from the distro. The also makes the udev rules file prettier (since it won't need to specify full path).

This machine is running Debian Squeeze. Is there some standard location for this file? I don't believe FHS or Debian Policy specifies one.

Improve this question

2 Answers 2

Reset to default
4

I would put these in /lib/udev if provided by a deb package and in /etc otherwise.

If you deploy the program on several machines, I recommend making a deb package; it will make deployment and version tracking easier. The Debian wiki has information, or you can read the Debian New Maintainers' Guide (ignoring the non-technical bits). dh makes this a breeze (there's even a dh_installudev).

If this is just for one machine, I'd put the binary in version control as well, or else check in the source and a makefile and ignore the binary. You may also want to put a symbolic link in /lib/udev. I don't recommend putting a non-packaged file in /lib/udev because you'll forget it's there.

Improve this answer
3
  • Packaging it is indeed a good idea, though this is going on one system (maybe eventually two), so I'm not sure its worth it, especially as I'm not worried about forgetting its there, as this is a well-documented server build. Binaries in /etc is not only a pain with version control (and ignoring the executable even worse, as then the rollback you thought you did, you didn't really, and your backups aren't complete, etc.), its also actually explicitly against FHS. But, having said that, "package it" is the best answer so far, and I'll accept it tomorrow if nothing better is suggested.
    – derobert
    Commented Nov 11, 2011 at 0:44
  • @derobert The FHS constrains distributions, not administrators. I don't think I've ever needed a binary in /etc, but if I did, I'd create a /etc/Makefile with compilation instructions.
    – Gilles 'SO- stop being evil'
    Commented Nov 11, 2011 at 0:50
  • 1
    While the FHS is indeed a standard for distros, ISVs, etc., following it in local administration strikes me as a best practice, so I'm automatically hesitant to do something it explicitly says not to. Thinking more about it, I'm going to package it, even though its only going on one system. That preserves the expectation that /lib is only for stuff from the package manager. (We have our own apt repositories, so it'll be easy to install, upgrade, etc, too)
    – derobert
    Commented Nov 11, 2011 at 1:09
1

/lib/udev looks rather reasonable. It will not interfere with anything not related to udev, so package management would not be much harmed. Other than this, you're left with a new subdirectory under /opt/ (will need full path).

Improve this answer
1
  • Well, /opt isn't necessarily on the root filesystem either. But yeah, so far I've just gone with putting it in /lib/udev.
    – derobert
    Commented Nov 10, 2011 at 22:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .