<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 13-09-30 06:24 PM, Peter Hutterer
      wrote:<br>
    </div>
    <blockquote cite="mid:20130930222448.GB6174@yabbi.redhat.com"
      type="cite">
      <pre wrap="">On Mon, Sep 30, 2013 at 01:56:53PM -0400, Gaetan Nadon wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">The location of the udevdir is obtained from pkg-config. This is generally
/lib/udev. Most people run their build scripts as non-root and do not want to
overwrite or add files on their workstation system.

This was not the behaviour in release 12.8.0. The code in configure.ac set
udevdir based on common installation prefixes /usr or /usr/local for which
the user would probably have root permission anyway. Other prefixes would
be assigned a udevdir value under the given $prefix.

The patch proposes the default location $libdir/udev/rules.d and no longer
seeking it's value from pkg-config, just like what was done for hal.
</pre>
      </blockquote>
      <pre wrap="">
is udevdir to be retired? iirc HAL never exported this as a variable
hence the hardcoded path, but I think relying on the udev package to tell
you where to look for data is the correct approach.</pre>
    </blockquote>
    The only usage of $udevdir is for the installation of the rules
    file, which must be done under $prefix. If one needs to get
    information from the real workstation  system udev, then yes, the
    corect approach would be to look in lib/udev/rules.d obtained from
    from pkg-config. However, I have not seen any such activity in any
    of the makefiles of C code.<br>
    <br>
    With the current git code, the problem is reversed. If I configure
    the module to install the rules file under $prefix, then I would be
    no longer able to "look for data" in the system udev.<br>
    <br>
    There are always two directories, the one under $prefix, and the
    real system directory which is mirrored by $prefix. Consider
    binaries and libraries. They install under $prefix, but can access
    other system bins and libs through environment variables that are
    providing an ordered path of locations. No such thing with udev. <br>
    <br>
    From the man page:<br>
    <blockquote>Rules files<br>
             The udev rules are read from the files located in the
      default rules<br>
             directory /lib/udev/rules.d/, the custom rules directory<br>
             /etc/udev/rules.d/ and the temporary rules directory<br>
             /run/udev/rules.d/. All rule files are collectively sorted
      and<br>
             processed in lexical order, regardless of the directories
      in which they<br>
             live. However, files in /etc/udev/rules.d/ take precedence
      over files<br>
             with the same name in /lib/udev/rules.d/; this can be used
      to ignore a<br>
             default rules file if needed.<br>
    </blockquote>
    These alternate location also require root access, so no help there.
    <br>
    <br>
    I think the patch is correct and is an improvement over the current
    code, but it does not address the "two directories" situation, the
    real one vs the $prefix one. If my assumption that there is no need
    to query the real udev system is correct, then the patch is all we
    need.<br>
    <br>
    <blockquote cite="mid:20130930222448.GB6174@yabbi.redhat.com"
      type="cite">
      <pre wrap="">

your patch has two changes: remove udev pkgconfig bits and change the
default. I agree with the latter, it seems the right thing to do, but not
the former.</pre>
    </blockquote>
    The former is still an open issue which the patch has slightly
    changed its manifestation.<br>
    <blockquote cite="mid:20130930222448.GB6174@yabbi.redhat.com"
      type="cite">
      <pre wrap="">

Cheers,
   Peter


</pre>
      <blockquote type="cite">
        <pre wrap="">The expectation is that the xorg source tree can be built from top to bottom
out of the box without tweaks or workarounds. A developer need to
manually install a rule under development and run an admin command for it to
take effect. Unlike binaries or libraries, there is no "path" style
variable to append a rule in development from a different location.

Signed-off-by: Gaetan Nadon <a class="moz-txt-link-rfc2396E" href="mailto:memsize@videotron.ca"><memsize@videotron.ca></a>
---
 configure.ac |   15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 52ea460..83a8488 100644
--- a/configure.ac
+++ b/configure.ac
@@ -91,17 +91,14 @@ AC_ARG_WITH(hal-fdi-dir,
 HAL_FDI_DIR=${halfdidir}
 AC_SUBST(HAL_FDI_DIR)
 
-
-PKG_CHECK_MODULES(UDEV, udev,
-                  [UDEV_RULES_DIR="`$PKG_CONFIG --variable=udevdir udev`/rules.d"],
-                  [UDEV_RULES_DIR=no])
-
+# Udev location for rules directory
 AC_ARG_WITH(udev-rules-dir,
            AS_HELP_STRING([--with-udev-rules-dir=DIR],
-                          [Default udev rules.d directory
-                           [[default=($prefix)/lib/udev/rules.d on Linux, none otherwise]]]),
-           [UDEV_RULES_DIR="$withval"],
-           [])
+                          [Directory where udev expects its rules files
+                          [[default=$libdir/udev/rules.d]]]),
+           [udevdir="$withval"],
+           [udevdir="$libdir/udev/rules.d"])
+UDEV_RULES_DIR=${udevdir}
 AC_SUBST(UDEV_RULES_DIR)
 AM_CONDITIONAL(HAS_UDEV_RULES_DIR, [test "x$UDEV_RULES_DIR" != "xno"])
 
-- 
1.7.9.5

</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>