From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Robby Workman <rworkman@slackware.com>
Cc: Andreas Oberritter <obi@linuxtv.org>,
linux-media@vger.kernel.org,
Patrick Volkerding <volkerdi@slackware.com>,
Hans De Goede <hdegoede@redhat.com>,
linux-hotplug@vger.kernel.org
Subject: Re: [PATCHES] Misc. trivial fixes
Date: Tue, 03 May 2011 03:42:44 +0000 [thread overview]
Message-ID: <4DBF79B4.5040000@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1105021926220.25339@connie.slackware.com>
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 <rworkman@slackware.com>
>>> X-Patchwork-Id: 699151
>>> Message-Id: <alpine.LNX.2.00.1104111908050.32072@connie.slackware.com>
>>> To: linux-media@vger.kernel.org
>>>
>>> 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.
next prev parent reply other threads:[~2011-05-03 3:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LNX.2.00.1104111908050.32072@connie.slackware.com>
[not found] ` <4DA441D9.2000601@linuxtv.org>
[not found] ` <alpine.LNX.2.00.1104120729280.7359@connie.slackware.com>
[not found] ` <4DA5E957.3020702@linuxtv.org>
[not found] ` <4DBF126D.6060807@redhat.com>
2011-05-03 2:48 ` [PATCHES] Misc. trivial fixes Robby Workman
2011-05-03 3:42 ` Mauro Carvalho Chehab [this message]
2011-05-03 4:07 ` Robby Workman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DBF79B4.5040000@redhat.com \
--to=mchehab@redhat.com \
--cc=hdegoede@redhat.com \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=obi@linuxtv.org \
--cc=rworkman@slackware.com \
--cc=volkerdi@slackware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).