Bug#345101: [Pkg-alsa-devel] alsa-tools

Michael Prokop 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[0] = ztrdup("/bin");
    | path[1] = ztrdup("/usr/bin");
    | path[2] = ztrdup("/usr/ucb");
    | path[3] = ztrdup("/usr/local/bin");
    | path[4] = 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
Type: application/pgp-signature
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 mailing list