[PATCH input-vmmouse] tools: make install fails when user has no write permission in /lib

Gaetan Nadon memsize at videotron.ca
Fri Oct 11 15:17:56 PDT 2013


On 13-10-04 01:55 AM, Peter Hutterer wrote:
> On Mon, Sep 30, 2013 at 11:59:57PM -0400, Gaetan Nadon wrote:
>> On 13-09-30 06:24 PM, Peter Hutterer wrote:
>>> On Mon, Sep 30, 2013 at 01:56:53PM -0400, Gaetan Nadon wrote:
>>>> 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.
>>> 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.
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> From the man page:
>>
>>     Rules files
>>            The udev rules are read from the files located in the default
>>     rules
>>            directory /lib/udev/rules.d/, the custom rules directory
>>            /etc/udev/rules.d/ and the temporary rules directory
>>            /run/udev/rules.d/. All rule files are collectively sorted and
>>            processed in lexical order, regardless of the directories in
>>     which they
>>            live. However, files in /etc/udev/rules.d/ take precedence
>>     over files
>>            with the same name in /lib/udev/rules.d/; this can be used to
>>     ignore a
>>            default rules file if needed.
>>
>> These alternate location also require root access, so no help there.
>>
>> 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.
> ok, fair enough. but that brings up the next question: $libdir is /usr/lib,
> right? so if you want to install into /lib/udev/rules.d you need something
> else than $libdir. On Fedora that's the same directory nowadays, but on
> other distros /lib and /usr/lib are separate.

In configuration.ac, the default value of udevdir is:

    Before the patch:   `$PKG_CONFIG --variable=udevdir udev`/rules.d"
    After the patch:        "$libdir/udev/rules.d"

In my Makefile:

    prefix = /home/nadon/xorg/inst
    exec_prefix = ${prefix}
    libdir = ${exec_prefix}/lib

    Before the patch:

        UDEV_RULES_DIR = /lib/udev/rules.d      (no root, install fails)

    After the patch:

        UDEV_RULES_DIR = ${exec_prefix}/lib/udev/rules.d   (no root,
        successfully installs)

If I want to install the rule file somewhere the system will actually
pick it up, I configure the module with
--with-udev-rules-dir=/lib/dev/rules.d. In the Makefile :

    UDEV_RULES_DIR = /lib/udev/rules.d

Obviously I must be aware I have chosen a location which requires root
permission. I must then install using "sudo make install".

It all boils down to have a sensible default value which does not
require root permission so the build does not break.

When you have a complete X source tree, all files install under $prefix,
so you have access to everything. Udev is not part of X, so you can't
"install in udev dirs" naturally by default.

Note that autoconf does not have a convenience installation directory
for udev:

    Fine tuning of the installation directories:
      --bindir=DIR            user executables [EPREFIX/bin]
      --sbindir=DIR           system admin executables [EPREFIX/sbin]
      --libexecdir=DIR        program executables [EPREFIX/libexec]
      --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
      --sharedstatedir=DIR    modifiable architecture-independent data
    [PREFIX/com]
      --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
      --libdir=DIR            object code libraries [EPREFIX/lib]
      --includedir=DIR        C header files [PREFIX/include]
      --oldincludedir=DIR     C header files for non-gcc [/usr/include]
      --datarootdir=DIR       read-only arch.-independent data root
    [PREFIX/share]
      --datadir=DIR           read-only architecture-independent data
    [DATAROOTDIR]
      --infodir=DIR           info documentation [DATAROOTDIR/info]
      --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
      --mandir=DIR            man documentation [DATAROOTDIR/man]
      --docdir=DIR            documentation root
                              [DATAROOTDIR/doc/xf86-input-vmmouse]
      --htmldir=DIR           html documentation [DOCDIR]
      --dvidir=DIR            dvi documentation [DOCDIR]
      --pdfdir=DIR            pdf documentation [DOCDIR]
      --psdir=DIR             ps documentation [DOCDIR]



>
> Cheers,
>    Peter
>
>
>>> 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.
>> The former is still an open issue which the patch has slightly changed
>> its manifestation.
>>> Cheers,
>>>    Peter
>>>
>>>
>>>> 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 <memsize at videotron.ca>
>>>> ---
>>>>  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
>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131011/72aaf1b9/attachment-0001.html>


More information about the xorg-devel mailing list