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.
WARNING: multiple messages have this Message-ID (diff)
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 00:42:44 -0300 [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: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 2:10 [PATCHES] Misc. trivial fixes Robby Workman
2011-04-12 2:14 ` Robby Workman
2011-04-12 12:13 ` Andreas Oberritter
2011-04-12 14:31 ` Robby Workman
2011-04-13 18:20 ` Andreas Oberritter
2011-05-02 20:22 ` Mauro Carvalho Chehab
2011-05-03 2:48 ` Robby Workman
2011-05-03 2:48 ` Robby Workman
2011-05-03 3:42 ` Mauro Carvalho Chehab [this message]
2011-05-03 3:42 ` Mauro Carvalho Chehab
2011-05-03 4:07 ` Robby Workman
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.