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 BABD1138A75 for ; Sat, 16 Feb 2013 06:14:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5537CE0586; Sat, 16 Feb 2013 06:13:58 +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 4C7B6E055C for ; Sat, 16 Feb 2013 06:13:57 +0000 (UTC) Received: from [192.168.107.2] (50.sub-75-192-42.myvzw.com [75.192.42.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id 0421533D98A for ; Sat, 16 Feb 2013 06:13:55 +0000 (UTC) Message-ID: <511F23B5.7060905@gentoo.org> Date: Sat, 16 Feb 2013 01:14:13 -0500 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130128 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] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1) References: <5117560B.3090709@gentoo.org> <20130210174634.77631769@sf> <1360508715.26312.8.camel@belkin4> <20130212113814.598ac903@ritchie.cs.ubc.ca> <20130212143040.3b1bd00d@ritchie.cs.ubc.ca> In-Reply-To: <20130212143040.3b1bd00d@ritchie.cs.ubc.ca> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 092f2e7e-1ca6-438b-8869-2a8e0e6210ed X-Archives-Hash: c9ede5dfcc728ebb00db2b1b9de55ed9 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2013 05:30 PM, Christopher Head wrote: > On Tue, 12 Feb 2013 20:51:15 +0000 (UTC) > Duncan <1i5t5.duncan@cox.net> wrote: > >> Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as >> excerpted: >> >>> On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman >>> wrote: >>> >>>> On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani >>>> wrote: >>>>>> +1 from me; I've had a few machines break on kernel upgrades >>>>>> because I didn't have the proper firmware installed (I guess >>>>>> older kernel sources came with the firmware?). >> >>>>> For starters, if kernel sources provide /lib/firmware, how do you >>>>> deal with file collisions? >>> >>> Please don't make kernel sources RDEPEND on firmware. The kernel >>> DOES NOT depend on firmware to work properly. Well over half my >>> machines prove that: they work perfectly fine (read: 100% of their >>> hardware works) with no firmware at all installed. >> >> Not a problem as long as the RDEPEND is under USE=firmware or similar. >> No USE=firmware, no rdepend! =:^) >> >> Kernel sources providing /lib/firmware itself shouldn't be a problem >> either, as that's just a dir, which many packages may own. The >> individual firmware files would be a problem, but the USE=firmware >> RDEPEND solution should solve that. >> > > Yes, of course, I meant please don’t depend unconditionally. A > conditional depend is fine by me, and I don’t care about one random > directory being created—I just don’t want a whole package being pulled > in for nothing. > While much of this thread is un-actionable I believe this is a good idea to do. What is everyone's opinion of adding a USE=firmware option to pull in PDEPEND="linux-firmware" in linux-2.eclass? Thanks, Zero -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHyO1AAoJEKXdFCfdEflKV/UQAI3NTvDcGQs7hjzhkecIgxNh 11OLTv43CxLRUg4OeYJppeavxvV//LPIdroVUS2e7GgF3fQ++8HKa5s9xUzi7pmy FoWgzoTG+IeTu7NF6MVMbyLO1hhH59+TEapBn4IFE4Da7qgK+3JrbF7Lx4cpxgnL s7pJxQ2Fvm6x8Bz7NUwi4R1xnYKUJhEvxOJVCtWeChjr8c2u0zHahHnmAs9bdyeF pnE4O7RD4I+lBUNI4kJGVM8EMK31LwFLgfyHkX8mPUyXQ9rA5+ofnxAHRIuV2zEA g1f59f8b46VUy3mAJ296EXz//GZ+KxMtucAAwNLpEHEKoEj4Ypyb7rfQTlsSxUXu kXVpB7bcDah5wT4i++UFpzzTx+wLVUxgOf/idRCUqDB8l2VqSSIqq6yJ+YA3eLoY wCd9wEXR2sHaHxlwYvakMr0na3lAMIopPAM0t/0cwwIJYXlScYw6f5iEUDSo1if6 B+pUw7Hst4XsRWcQpzfjnR3tiKK9U7vTc58blz7pkkZo2cV/+PLlFzQf+WlPaxzU ZRzcxoZnQFDifu/eXLQdVNzIfAuAzCYXiU2Rv3gowmwXlUuCQiyYcYUioCMRwFwt 7yPEXIGsMCX02sjLammF9ZM2RdyKjt/daKc1vMU29aMF/WB8T1nYUKVY/XZmJ+YR YrDEf3MaIKbKoXXRuINy =y/cz -----END PGP SIGNATURE-----