From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14666 invoked from network); 18 Sep 2004 19:10:45 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 18 Sep 2004 19:10:45 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1C8kbh-0003Bt-Me for arch-gentoo-dev@lists.gentoo.org; Sat, 18 Sep 2004 19:10:49 +0000 Received: (qmail 31346 invoked by uid 89); 18 Sep 2004 19:10:36 +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 16040 invoked from network); 18 Sep 2004 19:10:35 +0000 From: Anthony Gorecki To: gentoo-dev@lists.gentoo.org Date: Sat, 18 Sep 2004 12:09:16 -0700 User-Agent: KMail/1.7 References: <200409180057.34014.anthony@ectrolinux.com> <200409181103.01872.anthony@ectrolinux.com> <200409182129.09298.danarmak@gentoo.org> In-Reply-To: <200409182129.09298.danarmak@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1966548.spNgqGPhXx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409181209.23826.anthony@ectrolinux.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on selene.nvanc.ectrolinux.com X-Spam-Status: No; 0.0 hits out of a required 6.0 X-Spam-Results: Bayes: 0.5 Subject: Re: [gentoo-dev] Segregating KDE? X-Archives-Salt: 18d69d9e-ac0c-4818-92b3-3d53197b9621 X-Archives-Hash: edfbeeba839f80065f6b1c1afc6531da --nextPart1966548.spNgqGPhXx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 18 September 2004 11:29 am, Dan Armak wrote: > I don't understand what you mean by pseudo-packages, unless it's the > DO_NOT_COMPILE thing below. Please elaborate. I would have used "virtual packages", however I don't believe they provide = the=20 functionality that the subsequent example would have required. > Which doesn't scale, because portage can't manage those dependencies. You > can't depend on just one piece of kdebase (eg khtml) this way, and you > can't add/remove just one piece without also recompiling all other pieces > you want to keep. It would certainly require a fair amount of new scripting, regardless of ho= w=20 the system was implemented. Regarding adding and removing packages, what prevents Portage from compilin= g=20 only the KMail components (and dependencies) of the kdepim package, and the= n=20 merging it onto the filesystem? Likewise, they could be removed in a simila= r=20 fashion. It seems as though the only major difference is that the source=20 files would be stored in a shared archive rather than an independent archiv= e. > This and similar solutions have been discussed to death before now, see b= ug > #11123. I have, though we're still no closer to an actual solution. Bug #11123 was= =20 last updated quite a while ago, and I don't believe that twelve replies=20 constitutes a heavily discussed topic. I don't mean to seem abrasive, howev= er=20 this issue needs to be addressed, not deferred. > I mentioned 'most people' simply to point out that we're assigning limited > resources to the greatest demand. As Caleb says, with enough maintainers > this would be quite doable (provided the config caching portage enhanceme= nt > alleviated the performance issue). I realize that community support only extends as far as it is volunteered, = but=20 perhaps instead of simply stating that it would be possible with more=20 contributions and passing off the topic, a more concrete solution can be=20 found?=20 At the very least, if the Gentoo community were to agree on the best way to= =20 implement the KDE package segregation, regardless of the required volunteer= =20 time, it would be a step in the right direction. I would certainly be willi= ng=20 to volunteer in helping to maintain the packages if they could be properly= =20 handled by Portage. You mentioned "enough" maintainers. Assuming that the current maintainers a= re=20 already strained with keeping packages up-to-date, approximately how many n= ew=20 volunteers would be needed? =2D-=20 Anthony Gorecki Ectro-Linux Foundation --nextPart1966548.spNgqGPhXx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.10 (GNU/Linux) iQIVAwUAQUyH478NHCarD3E0AQI5sxAAmzCo6pWJtvL6sXiu2hteRfDhcv/DBuad aELfEIzkKAFGk99xgbwgU9tHv/mtps/nmeAgVH8SCvw1flQuBbBQeMfDVkl5WlDr YNmb6Rfhl8ljf4z/hB0shIJRVrt15UpGeFwqDXSf8ULlcjA3yaYk7CMIdNKA4uoU GsrYlHsWpMBYrXUUkVte0c+gimVSe4n+cHaWeYrS/klrXRyMOnnL6sF+TmLJ6Fhj 8bzR5dAAkNWmNmLVItrvgdwkBgbL6AYSN3KAeeyoRTMKRldig9QuUqNJaTfKTwdk POW8b2skeQFbG9b+7cXo2XANiIvJYhpwDSjzJAENBROWimooSMGCHgm9W9BjFT4x xVcXEPd2K6FyU/PSRWT7bwMrxUp1bsnugtsd+m/iKjzPKmaNf+DRo//Nb0Am4eom iLDWwDhtPQhOE+GJOlYvWnVFgVpWZ4nG7tp0qPSg5VYpvIqADznEaQJuH1+UniqM BWJuhB5EZKiEaOHov+MN6RaOWC1N5Kryg4h8seujXAe2BkDxfNtAWT43WBwQhETE 4xeEvoYiTYMXDjx8bihPB2IvuC9Wr/o5+hL79QYzovdEsM8DnWH8vWvMHMproME0 BM26lHH3cbl+3dTBbXbdBQeqUrkdBGSOIPsaqzjSS+PEHUA6Jql+DLKXaNrCQU7k Ssv+Ai4X+Y4= =LoSU -----END PGP SIGNATURE----- --nextPart1966548.spNgqGPhXx--