From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20373 invoked from network); 2 Jan 2004 07:31:58 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 2 Jan 2004 07:31:58 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1AcJmn-0003FD-RT for arch-gentoo-portage-dev@lists.gentoo.org; Fri, 02 Jan 2004 07:31:57 +0000 Received: (qmail 3940 invoked by uid 50004); 2 Jan 2004 07:31:56 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 24349 invoked from network); 2 Jan 2004 07:31:55 +0000 From: Scott Taylor To: gentoo-portage-dev@lists.gentoo.org In-Reply-To: <1073027790.3678.24.camel@big_squirt.dol-sen.ca> References: <1073027790.3678.24.camel@big_squirt.dol-sen.ca> Message-Id: <1073028705.11194.66.camel@Star.BerthoudWireless.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 02 Jan 2004 00:31:46 -0700 Subject: Re: [gentoo-portage-dev] multiple kernel driver emerges X-Archives-Salt: f2bd0c35-5855-4c3d-96eb-192f6b6bbb31 X-Archives-Hash: cdd29a504fd8649d23d0b1a77363199d The wisdom that had been passed on to me to protect things like that from being deleted *by portage* is to "touch filename" on the appropriate modules in the lib/modules/... directory. Because if its been modified, portage is not supposed to remove it. The other issue that comes up is when compiling the kernel itself, the kernel's "make modules_install" and such cleans out all the files in /lib/modules/kernel-*/kernel/... This is a nuisance in that you may easily forget to re-emerge the outside modules (xfree-drm for example). It appears though that anything in a non-kernel-made directory like /lib/modules/kernel-*/[misc,local] does not get erased when the kernel is rebuilt. So you might try copying such modules to a different subdirectory of your own choosing. If its not where portage put it, portage won't yank it. If its not where the kernel's make cleans out, that won't delete it either. Doing that means manual effort (and the chance to overlook it) if the module itself gets re-emerged. Perhaps there could be a way for an ebuild to mark a file as one that is allowed to be overwritten but not backed out? That might even be able to be done by making portage "forget" the timestamp of a kernel module whenever its installed. Since the timestamp wouldn't match what is on the disk, it wouldn't delete it, but the next emerge could overwrite it... On Fri, 2004-01-02 at 00:16, Brian wrote: > A problem that I (and others) have is portage unmerging kernel drivers > from an existing kernel when emerging them to a new kernel. > ala > > emerge nvidia-kernel > emerge alsa-driver > > unmerges the driver from your current kernel before you have a known > good new kernel. > > Is there a current method for doing so that I missed? If not could an > additional protected flag be set to prevent unmerging if the kernel > version is different than the last emerge of the driver, similar to the > slot #? > > it would make life a lot easier for noobs & non experts to work out > kerenel configs without messing up a working kernel. -- Scott Taylor - furbling, v.: Having to wander through a maze of ropes at an airport or bank even when you are the only person in line. -- Rich Hall, "Sniglets" -- gentoo-portage-dev@gentoo.org mailing list