[gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d

[gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d

[Samuli Suominen]

I see a lot of packages installing /etc/modprobe.d when it should be 
treated like /etc/udev, so only generated files and users own files

I'm suggesting converting ebuilds to install into /lib/modprobe.d and 
then tell users to copy it to /etc/modprobe.d for editing and replacing 
the run of the same from /lib/modprobe.d

just like you would now copy .rules to /etc/udev/rules.d and edit them 
there, instead of directly in /lib/udev/rules.d/

/lib should be static, just like /usr, and should be allowed to mount RO

did I miss something?

if not, i'll open a Tracker to get this done

(when do we get rid of /usr/portage again, and when will /usr/src be 
symlink to somewhere where it can be writable?)

Re: [gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d

[Rich Freeman]

On Sun, Jan 27, 2013 at 10:08 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> I see a lot of packages installing /etc/modprobe.d when it should be treated
> like /etc/udev, so only generated files and users own files

On a related note, I just noticed that /etc/udev is loaded with
orphans in my case, and I can't imagine I'm the only one.  When we
make moves like this we should include either news items or elogs or
something to tell users to clean out the cruft, otherwise config
protection tends to leave it there, and then users fail to get updates
since their cruft overrides them.

I assume that files that aren't user-edited can just be safely deleted?

Rich

Re: [gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d

[Samuli Suominen]

On 27/01/13 18:00, Rich Freeman wrote:
> On Sun, Jan 27, 2013 at 10:08 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> I see a lot of packages installing /etc/modprobe.d when it should be treated
>> like /etc/udev, so only generated files and users own files
>
> On a related note, I just noticed that /etc/udev is loaded with
> orphans in my case, and I can't imagine I'm the only one.  When we
> make moves like this we should include either news items or elogs or
> something to tell users to clean out the cruft, otherwise config
> protection tends to leave it there, and then users fail to get updates
> since their cruft overrides them.
>
> I assume that files that aren't user-edited can just be safely deleted?

I don't have anything there myself; only had 80-net-name-slot.rules and 
wanted new networking scheme so deleted that one too.
Most certainly 70-persistent-* cruft can go if you haven't edited them 
yourself.
What else do you have?
Currently the postinst messages of udev cover these two cases of 70- 
files, -cd.rules and -net.rules
And you are right, if they are not user edited then they can go. There 
is no "rule_generator" anymore in new udev so there shouldn't be any 
generated files anymore either, AFAIK