Using -p as option to specify the path is a poor choice since it clashes
with the generic -p option which is used to specify the package.

Looking at e.g. gnome-shell's debian/rules, I'm actually not sure what
the result of this call will be:
dh_girepository -p$(cdbs_curpkg) -l src -p /usr/lib/mutter

The answer seems to be that -p is always interpreted as dh_girepository's
local -p option, and the second -p overwrites the first, so it's
equivalent to dh_girepository -l src -p /usr/lib/mutter. To get the
effect that was intended, write:
    dh_girepository --package=$(cdbs_curpkg) -l src -p /usr/lib/mutter

Regards,
    smcv

Hi

I would recommend that `dh_girepository` would detect `-p` without a `/`
(or without `:`) and produce an error or a warning for that case until a
better solution comes around.

A path without `/` implies a top-level directory, which is in itself
exceedingly unlikely to be intentional for `-p` and therefore a very
strong indicator that someone wanted `-p <pkg>`.

Secondly, even if the user *wanted* that top-level directory, it is
trivial to bypass the check by prefixing with ./ or adding a trailing
slash - both would clearly mark it as "not a package" and happens to
work with path looks up out of the box.

Code-wise, this would be something like:

```diff
  if ($dh{P_PARAMS}) {
+    if ($dh{P_PARAMS} !~ m{[/:]}) {
+        error("Use --package ... or prefix path with './' ...");
+    }
      push @privdirs, split /:/, $dh{P_PARAMS};
  }
```
(hand-written delta; not expecting it to apply)

With this, there would at least be less surprises that the user would
not be using the standard debhelper `-p` for cases that uses a package name.

If you want to do a more permanent fix where `-p` goes back to being the
regular `debhelper -p`, I can recommend using a compat check to
conditionally assign the `-p` and we can document the change in the
standard debhelper compat upgrade check list.

Best regards,
Niels