ifupdown-ng / ifupdown-ng

flexible ifup/ifdown implementation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

add additional executor directories

CosmicToast opened this issue · comments

Some systems operate in semi-stateless mode (i.e / and /usr are read-only).
Under these conditions, a user (even as root) can't install their own executors.
Further, even on systems that do not operate like this, it's a common assumption that /usr/libexec/$package is managed by the package(manager).

Two obvious candidates would be under /usr/local/libexec and /etc/network.

I can think of several ways to implement this, and would rather hear maintainer opinions before jumping in. (for example, it could be in the configuration, it could be done via a PATH-like variable, and so on)
User-installable (such as in /etc/network) executors should have priority over system-installed ones.

Hi,

hm I don't like executable stuff in /etc very much, so I'd opt for something in /usr/local (may that be /usr/local/libexec/ifupdown-ng/ or /usr/local/share/ifupdown-ng/ probably with an executor subdirectory).

I guess it would be best to make that configureable in /etc/network/ifupdown-ng.conf and allow user to set the path to the directory up to ifupdown-ng/.

I agree that making it configurable in ifupdown-ng.conf is best, and setting the default to handle /usr/libexec followed by /usr/local/libexec.
If we do that though, the configuration should be a PATH-like so users (in this case distribution maintainers) can do things like add a distribution-specific set of builtins (e.g /usr/share/ifupdown-ng-contrib).

For personal use just having the default handle two directories would be fine for me.
However, I would also be interested in porting ifupdown-ng to abyss and making it the default there, for which case I would want the full configurability (though that'll ultimately depend on time availability and so on).

agreed regarding make it PATH-like.