From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1875 invoked from network); 19 Sep 2004 14:55:12 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Sep 2004 14:55:12 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1C935z-0000fn-GK for arch-gentoo-dev@lists.gentoo.org; Sun, 19 Sep 2004 14:55:19 +0000 Received: (qmail 28728 invoked by uid 89); 19 Sep 2004 14:55:11 +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 5370 invoked from network); 19 Sep 2004 14:55:11 +0000 From: Dan Armak Reply-To: danarmak@gentoo.org Organization: Gentoo Technologies, Inc. To: gentoo-dev@lists.gentoo.org Date: Sun, 19 Sep 2004 17:56:17 +0300 User-Agent: KMail/1.7 References: <200409180057.34014.anthony@ectrolinux.com> <200409181103.01872.anthony@ectrolinux.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4082714.Y1MlbdTgzW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409191756.18289.danarmak@gentoo.org> Subject: Re: [gentoo-dev] Re: Segregating KDE? X-Archives-Salt: 83235e80-9518-4aae-84c6-32a0281af544 X-Archives-Hash: be916444c2ae989a7fc1ca67196746cb --nextPart4082714.Y1MlbdTgzW Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 19 September 2004 07:43, Duncan wrote: > Then, at the top of the file put a big hairy warning about how some > package components, particularly in kdebase, are depended on by others, > and to disable the use flag and recompile all packages if there are > dependency issues, and then leave everything else up to the user. Any > bugs on related dependency issues would be marked invalid, see the warning > in the file, etc. so it wouldn't become a big support issue.=20 As you say, this solution is hairy (or anything else that doesn't create re= al=20 separate ebuilds for the separate apps). I personally don't like it at all= =20 and don't really want to see it happen even as an alternative to nothing at= =20 all, because it's so ugly. Of course, it's very easy to implement, but it=20 takes away all the advantages of having a proper package manager - all the= =20 advantages of using portage rather than state-less invocations on the order= =20 of 'ebuild.sh file.ebuild'... And of course this solution entails more or less not supporting it despite= =20 having it in the portage tree - marking related bugs as invalid etc. That's= =20 another reason I don't like it. Perhaps I don't have the right to say this at this point, having been incat= ive=20 for over a year, but this solution simply takes away too much functionality= =20 and support from the user in order to decrease the maintainer's workload. =2D-=20 Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key =46ingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 --nextPart4082714.Y1MlbdTgzW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBTZ4SUI2RQ41fiVERAqghAJ9xTetU9SjV8mbhv0jbXTl9CQ3lrQCeLERa GYwjKecPfZs8LKgjs+alnuE= =V0px -----END PGP SIGNATURE----- --nextPart4082714.Y1MlbdTgzW--