[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