Em 02-05-2011 23:48, Robby Workman escreveu:
> 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 <[email protected]>
>>> X-Patchwork-Id: 699151
>>> Message-Id: <[email protected]>
>>> To: [email protected]
>>>
>>> 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?

If you don't mind, please re-send it. Please c/c me, as we're having some 
troubles with patchwork nowadays.

>> 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.

We've packaged v4l-utils for RHEL, via epel[1]. I volunteered to maintain it 
for RHEL6,
as I use it on my machine and I would be doing it anyway for me, so better to 
maintain
it for the others also ;)

[1] https://admin.fedoraproject.org/pkgdb/acls/name/v4l-utils

I don't intend to maintain it for RHEL5, but I was told that lots of mythtv 
users run
CentOS (based on RHEL5).  So, I won't doubt if someone from CentOS (or other 
rpm repos
for .el5, like atrpms) would add v4l-utils there.

>> 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).

Do you know, by any chance, what's the minimal udev version where /lib/udev 
exists?

If it is too old, then I agree that pointing the default to /lib/udev is the 
better.

>> 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/).

Ok. 

> 
> 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)  ;-)
Thanks!
> 
> -RW

Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to