linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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