From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A53BA1386E4 for ; Sun, 27 Jan 2013 16:49:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D10F721C006; Sun, 27 Jan 2013 16:49:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D1633E0663 for ; Sun, 27 Jan 2013 16:49:24 +0000 (UTC) Received: from [10.177.7.19] (212-226-42-68-nat.elisa-mobile.fi [212.226.42.68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id 70C6B33DB0A for ; Sun, 27 Jan 2013 16:49:23 +0000 (UTC) Message-ID: <51055A70.10006@gentoo.org> Date: Sun, 27 Jan 2013 18:48:48 +0200 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] /lib/modprobe.d vs. /etc/modprobe.d References: <510542D6.3070007@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: d1f261da-7c82-4bee-add4-8cdceb0683fc X-Archives-Hash: 6fb74bcfd1c538ec9cca2a7f6fa8d075 On 27/01/13 18:00, Rich Freeman wrote: > On Sun, Jan 27, 2013 at 10:08 AM, Samuli Suominen 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