Bug#345101: [Pkg-alsa-devel] alsa-tools
mika at grml.org
Fri Dec 30 14:58:40 UTC 2005
* Thomas Hood <jdthood at yahoo.co.uk> [20051230 15:15]:
> Jordi Mallach wrote:
> > Oh, btw, I modified alsa-base.modprobe to add the full path for
> > modprobe.
> I don't like to hard-code program paths, and I can quote some policy to
> back this up:
> > Programs called from maintainer scripts should not normally have a
> > path prepended to them. Before installation is started, the package
> > management system checks to see if the programs `ldconfig',
> > `start-stop-daemon', `install-info', and `update-rc.d' can be found
> > via the `PATH' environment variable. Those programs, and any other
> > program that one would expect to be on the `PATH', should thus be
> > invoked without an absolute pathname. Maintainer scripts should also
> > not reset the `PATH', though they might choose to modify it by
> > prepending or appending package-specific directories. These
> > considerations really apply to all shell scripts. [6.1]
Do you consider the /etc/modprobe.d/* files as shell scripts?
> If "modprobe" is failing on the user's system then either he doesn't have a
> sane default PATH or zsh is broken.
If $PATH is not set zsh falls back to the following:
,---- [ $ZSH/Src/init.c ]
| /* Set default path */
| path = (char **) zalloc(sizeof(*path) * 5);
| path = ztrdup("/bin");
| path = ztrdup("/usr/bin");
| path = ztrdup("/usr/ucb");
| path = ztrdup("/usr/local/bin");
| path = NULL;
That's what happens in the reported case so modprobe can't be
> (Or modprobe isn't passing PATH, but my testing indicates that
> this is not the problem.)
Where does modprobe set $PATH? (Sorry, I could not find anything.
I'm still investing on the problem, if it's really a zsh problem
I'll contact zsh-upstream of course.)
> In either case, other things are going to break on his system
> unless many packages hard code paths. And Debian decided a long
> time ago that it wasn't going to do that.
No, everything else works as expected.
> The submitter says that other files in /etc/modprobe.d/ include statements to
> call modprobe with full path; however, on my systems there are _no_ files
> besides alsa-base that include statements to call modprobe. So I am curious
> to know what other packages have hard coded modprobe's path.
For example dumputils and irda-utils.
> modprobe's location is unlikely to change, but in principle the admin is
> supposed to be able to substitute commands by putting them in /usr/local/bin/
> and modifying PATH to include /usr/local/bin before the standard dirs.
Even the documentation mentions "/sbin/modprobe":
,---- [ man 5 modprobe.conf ]
| install modulename command...
| This is the most powerful primitive in modprobe.conf: it
| tells modprobe to run your command instead of inserting the
| module in the kernel as normal. The command can be any shell
| command: this allows you to do any kind of complex processing
| you might wish. For example, if the module "fred" worked
| better with the module "barney" already installed (but it
| didn't depend on it, so modprobe won't automatically load
| it), you could say "install fred /sbin/modprobe barney;
| /sbin/modprobe --ignore-install fred", which would do
| what you wanted. Note the --ignore-install, which stops the
| second modprobe from re-running the same install command.
| See also remove below.
| You can also use install to make up modules which don't
| otherwise exist. For example: "install probe-ethernet
| /sbin/modprobe e100 || /sbin/modprobe eepro100", which will
| try first the e100 driver, then the eepro100 driver, when you
| do "modprobe probe-ether- net".
| If you use the string "$CMDLINE_OPTS" in the command, it will
| be replaced by any options specified on the modprobe command
| line. This can be useful because users expect "modprobe
| fred opt=1" to pass the "opt=1" arg to the module, even if
| there's an install command in the configuration file. So our
| above example becomes "install fred /sbin/modprobe barney;
| /sbin/modprobe --ignore- install fred $CMDLINE_OPTS"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/attachments/20051230/51f48f4a/attachment.pgp
More information about the Pkg-alsa-devel