Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Dienstag, 4. September 2007, Matthias Schwarzott wrote: On Samstag, 1. September 2007, Matthias Schwarzott wrote: On Samstag, 1. September 2007, Daniel Drake wrote: I like the idea of adding this to CONFIG_PROTECT_MASK. Ok seems we should do this! Next udev ebuild will add rules directory to CONFIG_PROTECT_MASK. I also tested now what happens to rule changes that get installed in the same turn as the MASK is added. etc-update and dispatch-conf both handle this case fine. udev-115-r1 has been commited. It now adds rules directory to CONFIG_PROTECT_MASK. -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Samstag, 1. September 2007, Matthias Schwarzott wrote: On Samstag, 1. September 2007, Daniel Drake wrote: I like the idea of adding this to CONFIG_PROTECT_MASK. Ok seems we should do this! Next udev ebuild will add rules directory to CONFIG_PROTECT_MASK. I also tested now what happens to rule changes that get installed in the same turn as the MASK is added. etc-update and dispatch-conf both handle this case fine. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
I like the idea of adding this to CONFIG_PROTECT_MASK. Matthias Schwarzott wrote: Only problem I see: What to do with people having custom modifications inside the default rules-files? I can't think of any cases where the user would have to do this (they can make custom modifications in their own files). Could we modify the rules files installed by udev to include a comment at the top warning that a default portage configuration will overwrite any changes that the user makes? Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Samstag, 1. September 2007, Daniel Drake wrote: I like the idea of adding this to CONFIG_PROTECT_MASK. Matthias Schwarzott wrote: Only problem I see: What to do with people having custom modifications inside the default rules-files? I can't think of any cases where the user would have to do this (they can make custom modifications in their own files). Could we modify the rules files installed by udev to include a comment at the top warning that a default portage configuration will overwrite any changes that the user makes? I have newer testing files locally, but as far as I remember udev-115 should contain this header on almost all rule files already. # do not edit this file, it will be overwritten on update Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Hi there! 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. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Friday 31 of August 2007 12:37:57 Matthias Schwarzott wrote: What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. That's what I did locally so fine by me. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! 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? Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! 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? Matthias Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Fri, 31 Aug 2007 16:12:52 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! 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? Matthias 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. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Friday 31 August 2007, Marius Mauch wrote: Petteri Räty [EMAIL PROTECTED] wrote: Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! 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 ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Hi! On Fri, 31 Aug 2007, Mike Frysinger wrote: On Friday 31 August 2007, Marius Mauch wrote: Petteri Räty [EMAIL PROTECTED] 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. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Fri, 2007-08-31 at 18:13 +0200, Tobias Klausmann wrote: 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. INSTALL_MASK = [space delimited list of file names] Use this variable if you want to selectively prevent certain files from being copied into your file system tree. This does not work on symlinks, but only on actual files. Useful if you wish to filter out files like HACKING.gz and TODO.gz. Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
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 [EMAIL PROTECTED] 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) -- [EMAIL PROTECTED] mailing list
