From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2503 invoked from network); 19 Sep 2004 19:46:11 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Sep 2004 19:46:11 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1C97db-0005ps-G3 for arch-gentoo-dev@lists.gentoo.org; Sun, 19 Sep 2004 19:46:19 +0000 Received: (qmail 31471 invoked by uid 89); 19 Sep 2004 19:46:10 +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 27096 invoked from network); 19 Sep 2004 19:46:10 +0000 From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Date: Sun, 19 Sep 2004 21:46:11 +0200 User-Agent: KMail/1.7 References: <200409180057.34014.anthony@ectrolinux.com> <200409191756.18289.danarmak@gentoo.org> In-Reply-To: <200409191756.18289.danarmak@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1550244.b3cj8FunXQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409192146.18527.pauldv@gentoo.org> Subject: Re: [gentoo-dev] Re: Segregating KDE? X-Archives-Salt: 31f005d7-8478-4eed-85e1-8940ffe22999 X-Archives-Hash: 22a0f65b6b370322b0a2c89003755151 --nextPart1550244.b3cj8FunXQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 19 September 2004 16:56, Dan Armak wrote: > 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. > > As you say, this solution is hairy (or anything else that doesn't create > real separate ebuilds for the separate apps). I personally don't like it = at > all and don't really want to see it happen even as an alternative to > nothing at all, because it's so ugly. Of course, it's very easy to > implement, but it takes away all the advantages of having a proper package > manager - all the advantages of using portage rather than state-less > invocations on the order of 'ebuild.sh file.ebuild'... > > And of course this solution entails more or less not supporting it despite > having it in the portage tree - marking related bugs as invalid etc. That= 's > another reason I don't like it. > > Perhaps I don't have the right to say this at this point, having been > incative for over a year, but this solution simply takes away too much > functionality and support from the user in order to decrease the > maintainer's workload. Well, I'll second you in any case. It is not a solution and offering someth= ing=20 willingly and then saying it is unsupported is in these kinds of cases a=20 medicine worse than the cure. The only "possible" solution I see would=20 involve useflags and useflag dependencies (still "in the works"). But I agr= ee=20 that we must avoid in any case to get back the stateless mess that the lack= =20 of dependency tracking entails. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart1550244.b3cj8FunXQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBTeIKbKx5DBjWFdsRAloFAKC+0lgTGx5HaLdCIuhBmNcarBH+5QCePvO8 IY/SkVazuA1XOh2oQOB3JNw= =fhCg -----END PGP SIGNATURE----- --nextPart1550244.b3cj8FunXQ--