[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
From:       Matthias Schwarzott <zzam () gentoo ! org>
Date:       2007-08-31 19:57:50
Message-ID: 200708312157.50675.zzam () gentoo ! org
[Download RAW message or body]

On Freitag, 31. August 2007, Tobias Klausmann wrote:
> Hi!
>
> On Fri, 31 Aug 2007, Mike Frysinger wrote:
> > On Friday 31 August 2007, Marius Mauch wrote:
> >> Petteri Räty <betelgeuse@gentoo.org> wrote:
> >>> Matthias Schwarzott kirjoitti:
> >>>> On Freitag, 31. August 2007, Matthias Schwarzott wrote:
> >>>>> What do you think about adding /etc/udev/rules.d/ to
> >>>>> CONFIG_PROTECT_MASK. This will no longer bother the user with
> >>>>> updating these files. Thus it will reduce the number of bugs
> >>>>> triggered by forgotten config-file updates.
> >>>>>
> >>>>> If user needs home-brewn rules he is requested to add own files,
> >>>>> and not use the already existing ones.
> >>>>
> >>>> Only problem I see: What to do with people having custom
> >>>> modifications inside the default rules-files?
> >>>
> >>> Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf?
> >>
> >> No, that wouldn't work. However they could add '-/etc/udev/rules.d' to
> >> CONFIG_PROTECT_MASK or add individual files to CONFIG_PROTECT.
> >
> > either solution sucks
> >
> > the question is, should people be modifying the default rules ?  is there
> > something in the default rules file that they cant accomplish in a sep
> > rules file ?  if so, then the dir cant be masked ...
>
> I find the persisten-net-generator.rules particularly annoying
> (for various reasons including, but not limited to system images
> and system cloning).
>
> So I have an empty file of that name and happily nuke whatever
> comes along with udev updates. I could of course unmask that
> file if it were to be masked in the future.
>
> Still, this reeks of layers upon layers of customization to me.
> I'd prefer a more elegant solution - although know of none. The
> classic approach would be a USE flag to toggle installation of
> the shipped udev files - which wouldn't work for me, as I only
> have gripes about *one* of them.
>
> There probably simply isn't a simple, elegant solution that is a)
> not wrong and b) works for just about everybody.
>

If your only regard is disabling persistent-net stuff you also can archive 
this without need to modify any files.

1. For almost all decisions udev does it is possible to overwrite them later, 
or assign a value with := instead of = before.
2. In special case of persistent-net: 75-persistent-net.rules does only catch 
a devices if no name is set at that point, that means it can by bypassed 
simply be doing this in some rule-file before:

SUBSYSTEM=="net", NAME="%k"

We have already thought about adding a config option to disable 
persistent-net, but we have not yet find a nice (from developer and user 
view) solution.

3. If there are annoyances in udev-rules, please inform us about this. We 
might have some kind of hardware, but there are lots of different possible 
configurations we have no idea of, so please bug us (best with solution ;) ).

Matthias

-- 
Matthias Schwarzott (zzam)
-- 
gentoo-dev@gentoo.org mailing list


[prev in list] [next in list] [prev in thread] [next in thread]