From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NnLSt-0008KS-GD for garchives@archives.gentoo.org; Fri, 05 Mar 2010 00:32:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B5D50E0E0E; Fri, 5 Mar 2010 00:32:19 +0000 (UTC) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.147]) by pigeon.gentoo.org (Postfix) with ESMTP id E58F6E0DA3 for ; Fri, 5 Mar 2010 00:32:17 +0000 (UTC) Received: by qw-out-1920.google.com with SMTP id 14so92242qwa.10 for ; Thu, 04 Mar 2010 16:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=e6HY4kx6LLon51WYLRTO7J56q4O5Xshx8PJ3gc0Zc6U=; b=aKezs9B351wW+3PPuvvRCZ1sHL+7egWdljcFY4bU7f17A1XAqaVs3Z8gwtauW/bOfH b7sddw62mIup3DHsecjFga07ZDxchSa7g2ZKmknwTdmHAjbWUcyycDfBm4kLWWj5R24A PxHvC9coOKzAimu89JwU+tRKI/oydn+g+Xp9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZwHjzRxtuo1iIKWzKHnFRv1/diTLyUIZnFGFR9FCE1NcKpH/45Rr4wZiNoFPmswlAI 6IqIKgqDpLnrqwhwdyCfCi5ksgaw1EWC223igKFhzq3Revc+60yYzlKkEaFbwC6ydXRv SyRHqhgJBiZvThbSA+KxcdGxin0fHhjQXTDRM= Received: by 10.224.38.213 with SMTP id c21mr1868209qae.309.1267749137600; Thu, 04 Mar 2010 16:32:17 -0800 (PST) Received: from smtp.gmail.com (c-98-210-130-131.hsd1.ca.comcast.net [98.210.130.131]) by mx.google.com with ESMTPS id 2sm1115945qwi.31.2010.03.04.16.32.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Mar 2010 16:32:16 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Thu, 04 Mar 2010 16:32:10 -0800 Date: Thu, 4 Mar 2010 16:32:10 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: Dale Subject: Re: [gentoo-dev] Re: [RFC] Remove cups from default profile to solve circular deps Message-ID: <20100305003210.GF9408@hrair> References: <1267641936.26170.5.camel@localhost> <201003040756.48943.cla@gentoo.org> <20100303230807.2a1ac862@angelstorm> <24205fb6ca08a56f3d4d8b14ae72b0ee@jolexa.net> <4B90489C.5000503@doublecreations.com> <4B904B35.4000202@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="at6+YcpfzWZg/htY" Content-Disposition: inline In-Reply-To: <4B904B35.4000202@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: f0bcb0e9-f335-4e7f-acf0-37376fc6f156 X-Archives-Hash: 76834acf4e489e847b77fceb2921b29b --at6+YcpfzWZg/htY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 04, 2010 at 06:07:17PM -0600, Dale wrote: > chrome://messenger/locale/messengercompose/composeMsgs.properties: > > On 03/04/10 12:53, Ben de Groot wrote: > >> Exactly. The last time I owned a printer is over 5 years ago. So I don= 't > >> think cups warrants to be in the standard desktop profile. > >> > >> Cheers, > > > > I print almost daily, but I'm not sure if printers are commonplace > > enough for cups to be a default. Some users may expect it though. > > > > As for the circular deps, it would seem more logical to fix the=20 > > problem at the source, rather than to cover it up for one subset of=20 > > users. > > > > > I can't think of anyone that doesn't have a printer. All my friends and= =20 > family that has a computer has a printer. Heck, I had a printer hooked= =20 > up to my old Vic-20 for goodness sake. That was over 20 years ago. A sampling size of one is of course representive of the whole. The=20 vast majority of gentoo deployments I deal in, cups is bloat- my=20 personal laptop, sure, that's a different story. That's well under a=20 tenth of my installs however. The point there is that one size doesn't fit all- we have inheritance=20 in the profiles for a reason. Shift cups out of the base and into=20 desktop specific profiles. That one shouldn't be a point of debate. > He wants to remove the USE flag so that it hides the fact it is not=20 > really fixed. If a person does their install as they should, the=20 > problem will be right there for them to deal with. Of course, the user= =20 > will the one getting pointed at since they added the flag. Two scenarios. 1) flag is left on by default. emerge pukes at them about the use=20 cycle, user has to go googling and try to figure out the way around=20 this (with the end result being "flip the flag off, merge stuff, flip=20 it back on, rebuild the affected pkgs" 2) flag is left off by default. things emerge fine, but user finds=20 they don't have printing. So... they google it, find out that they=20 need to turn a use flag on and then do an emerge -N. Of the two *viable* scenarios, #2 is frankly the one that's going to=20 be less of a pita to users- the folk who need cups on a desktop have a=20 clear and simple path to getting cups, versus #1 which requires the=20 user to understand dependency cycles induced by use state. One thing to note- for #1, the user is going to have to do the same=20 steps as #2, they're just going to hit a terse failure instead of=20 finding that when they go to print, they need to rebuild w/ cups=20 support on. #2 contains the issues/breakage a helluva lot more than=20 #1 does. > It takes the problem off the people that created it and adds it to=20 > the user. That is not how it should be fixed. Lay off pointing fingers. Cycles exist and are rather hard to fix- if=20 in doubt I strongly suggest you do some research into how stages are=20 built (and the existance of the build use flag). The problem is the=20 interdependence in the raw src itself, not ebuild devs. The use state induced hard dependency cycle issue has been known for a=20 long while- the solution to this requires the resolver being able to=20 break the cycle via building the pkg multiple times with the use=20 state varied to break cycles (as far as I know, none of the PMs do=20 this although pkgcore could at one point). Modifying the resolver to do that sort of cycle breaking is rather=20 tricky- work should be done towards it, but it's not the sort of=20 thing that's going to be implemented today, and stabled tomorrow. Basically, punt the flag if you don't want users to hit a cycle on=20 fresh installs- it's the only option that exists *now* (and those=20 screaming should focus their efforts on implementing the use cycle=20 breaking I mentioned above). ~harring --at6+YcpfzWZg/htY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkuQUQoACgkQsiLx3HvNzgcHowCfZlpx2XPqbaNQJ98YhiIl8ThT M0sAoMzrWzWFCI23wrDTANwXajbU9dYb =C8p2 -----END PGP SIGNATURE----- --at6+YcpfzWZg/htY--