On Mon, 2 May 2011, Mauro Carvalho Chehab wrote:
Not sure what happened, but I lost the original email, so let me quote
it from patchwork ID#699151.
Subject: [PATCHES] Misc. trivial fixes
Date: Tue, 12 Apr 2011 02:10:36 -0000
From: Robby Workman <rworkman@xxxxxxxxxxxxx>
X-Patchwork-Id: 699151
Message-Id: <alpine.LNX.2.00.1104111908050.32072@xxxxxxxxxxxxxxxxxxxx>
To: linux-media@xxxxxxxxxxxxxxx
Patch #1 installs udev rules files to /lib/udev/rules.d/ instead
of /etc/udev/rules.d/ - see commit message for more info.
Patch #2 allows override of manpage installation directory by
packagers - see commit message for more info
Please send each patch in-lined, one patch per email.
Okay, noted. Should I resend, or is this for future reference?
This creates MANDIR in Make.rules and keeps the preexisting
default of /usr/share/man, but allows packagers to easily
override via e.g. "make MANDIR=/usr/man"
... snipped lots ...
+MANDIR = /usr/share/man
It would be better to define it as:
MANDIR = $(PREFIX)/share/man
As suggested by Andreas.
Yes, I sent a fixed patch later - perhaps a resend is better
regardless now? :-)
... snipped lots ...
- install -m 755 -d $(DESTDIR)/etc/udev/rules.d
- install -m 644 -p 70-infrared.rules $(DESTDIR)/etc/udev/rules.d
+ install -m 755 -d $(DESTDIR)/lib/udev/rules.d
Not all distros use /lib for it. In fact, RHEL5/RHEL6/Fedora 15 and Fedora rawhide
all use /etc/udev/rules.d.
If so, it's only older distros that I wouldn't expect to be packaging newer
versions of v4l-utils (e.g. RHEL won't as I understand it), and for Fedora,
if "rawhide" is devel tree, then I'm pretty sure you're mistaken.
In a matter of fact, looking at RHEL6 (udev-147-2.35.el6.x86_64), it has both. I suspect
that /lib/udev/rules.d is meant to have the default scripts that are part of the
official packages, and /etc/udev/rules.d to be user-defined ones. So, at least on RHEL6,
it makes sense that a user-compiled tarball would install stuff into /etc/*, and
that a RHEL6 package would change it to install at /lib/*.
Every distro (recent) will have both /lib/udev/rules.d/ and /etc/udev/rules.d/ ;
more on that later...
So, it is better to have some Makefile var with some default, that
allows overriding it when doing a make install, for example:
UDEVDIR=/etc/udev/rules.d
Well, if you *insist* on doing this, sure, but better to do this:
UDEVDIR=/lib/udev
as the default, and then use $(UDEVDIR)/rules.d/ (and let packagers
redefine UDEVDIR if desired - though I don't think that will be as
common as you believe).
The default is a matter of personal taste. I would keep the current way as default,
as it avoids breaking for those that are using it on the current way. One alternative
would be to add some logic there to change the default to /lib/* if /etc/* doesn't
exist.
But /etc/udev/rules.d/ should exist regardless, and it's not at all a
matter of personal taste, as I understand it. /lib/udev/rules.d/ is
the location for packaged and general default rules files to be placed,
and /etc/udev/rules.d/ is where autogenerated rules (such as those that
create persistent symlinks for optical and network devices) are placed,
as well as admin- and system-specific override rules (e.g. a file named
10-blah.rules in /etc/udev/rules.d/ would completely override a file of
the same name in /lib/udev/rules.d/).
The point I'm trying to make is this: you lose nothing in the way of
user customization by defaulting to /lib/udev/rules.d/ - you simply
force it to happen the way that upstream udev intends. The only thing
you lose is support for older udev releases, and I'm not sure that's
a big concern :-)
(CC'd udev mail list so that someone can LART me if I'm wrong) ;-)
-RW
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
