From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26022 invoked by uid 1002); 5 Oct 2003 00:48:52 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 5896 invoked from network); 5 Oct 2003 00:48:52 -0000 Date: Sun, 5 Oct 2003 02:48:42 +0200 From: Patrick =?ISO-8859-1?Q?B=F6rjesson?= To: gentoo-dev@gentoo.org Message-Id: <20031005024842.2ceeaee1.psycho@rift.ath.cx> In-Reply-To: <1065310682.18158.4.camel@rattus.localdomain> References: <3F7D4315.1020900@gentoo.org> <200310041436.43568.luke-jr@gentoo.org> <20031004175629.09f342a0.psycho@rift.ath.cx> <200310041729.52354.luke-jr@gentoo.org> <20031004202723.65d7ee16.psycho@rift.ath.cx> <1065310682.18158.4.camel@rattus.localdomain> Organization: HiS X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sun__5_Oct_2003_02_48_42_+0200_66E=tMcgTd20MZP8" Subject: Re: [gentoo-dev] Speaking of new kernels being added to the tree X-Archives-Salt: efdc2829-13dc-44f5-84cf-f09dd5af714a X-Archives-Hash: 5e36b01b24270e8723f85fa768a1af13 --Signature=_Sun__5_Oct_2003_02_48_42_+0200_66E=tMcgTd20MZP8 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > because a number of other packages want to see /usr/src/linux for the > running kernel. lm-sensors, vmware, nvidia, ... I was referring to the ordinary packages (not the kernels) when talking about moving the unpacked source from /var/tmp/portage/*/work to /usr/src. As it's almost always necessary for user-interaction when configuring the kernel it's needed for the source of the kernel to remain in /usr/src and not be removed as soon as emerge is finished doing it's thing. But the ordinary packages' source-code can be safely removed after the merge (if you don't want to do something special to the source in case you would use the ebuild-command instead). I thought it was pretty clear what I meant in my previous post... > I do agree that some effort should be put into fixing the unwanted > effects that occur when you install another kernel though (haveing to > reinstall all kernel related packages, and unable to keep already > installed versions) - I am sure someone must have had a bug against > that one. I'm sure alot of people do =3D) As am I. > On Sun, 2003-10-05 at 02:27, Patrick B=F6rjesson wrote: > > > In theory, Portage could track them if ebuild could be modified to > > > use/usr/src/pkg when it existed instead of /var/tmp/portage/*/work > > > and the application was installed via 'ebuild pkg merge'. I'm not > > > sure how possible that would be for implementation, though. > >=20 > > But then the question is: Why? We already have the source unpacked > > in/var/tmp/portage/*/work so why "move" it to /usr/src? There are > > already ways for people to do the configure- and make-steps them > > selves if they Patrick B=F6rjesson --=20 Public key id: 4C5AB0BF Public key available at search.keyserver.net[:11371] --Signature=_Sun__5_Oct_2003_02_48_42_+0200_66E=tMcgTd20MZP8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/f2puoil/ZExasL8RAk9bAKCS/HOwP5zZ+1VBephjKRS2sokcFQCgpEuV BLy0ZZ9JZfN/pk8lGG2Vxoc= =yY26 -----END PGP SIGNATURE----- --Signature=_Sun__5_Oct_2003_02_48_42_+0200_66E=tMcgTd20MZP8--