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 1NnNoL-0005uG-6N for garchives@archives.gentoo.org; Fri, 05 Mar 2010 03:02:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1AE80E0D12; Fri, 5 Mar 2010 03:02:43 +0000 (UTC) Received: from mail-gx0-f216.google.com (mail-gx0-f216.google.com [209.85.217.216]) by pigeon.gentoo.org (Postfix) with ESMTP id EB923E0B3B for ; Fri, 5 Mar 2010 03:02:23 +0000 (UTC) Received: by gxk8 with SMTP id 8so1390945gxk.9 for ; Thu, 04 Mar 2010 19:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bPOt/ypZwwF+Y0oP6wCjrLGv+C270PVoHJFdzMpoITo=; b=MHc295pU/AK529M2ZTHZfJKve+CymjnKo3qvCe+EZuBanxYNyGEGuROELKgHzojSYU dAiH0EwFeNa4lVIsEP7oYkajO2BViepKq1fMtRrO5IVZdF/IgpTITLzVabqkmZe1z1xx vCO87e2qEZ6xHZYVdp03c169qHbrW6RhWpXTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=WxRIDTvZbYY3pA4bXdrEavJ1XAoy37D+/SStRdPyK4WePHHTwmtTmeyta1Lfw6ohPq AeQZXihxVnkDYkNK9ZAF7k6G0eLwUVMbrbnIy8wNACDmMcoO8v8rbbB0CafbDa5u++C9 eBFcowL6Wd0br5nyZnP6Jm+XlRGEjXmKK0Wuk= Received: by 10.100.24.28 with SMTP id 28mr823143anx.220.1267758143516; Thu, 04 Mar 2010 19:02:23 -0800 (PST) Received: from [192.168.1.1] (adsl-0-94-66.jan.bellsouth.net [65.0.94.66]) by mx.google.com with ESMTPS id 13sm479431gxk.8.2010.03.04.19.02.21 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Mar 2010 19:02:22 -0800 (PST) Message-ID: <4B90743C.9070902@gmail.com> Date: Thu, 04 Mar 2010 21:02:20 -0600 From: Dale User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100304 Gentoo/2.0.3 SeaMonkey/2.0.3 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps References: <4B9049A3.5020805@gmail.com> <201003050957.22890.mail@patrick-nagel.net> <4B906E7D.7010003@gentoo.org> In-Reply-To: <4B906E7D.7010003@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 49af44f8-8ead-4a55-b489-cbfd898c9a6d X-Archives-Hash: 58fcfdf622dad420986249e8030c5644 chrome://messenger/locale/messengercompose/composeMsgs.properties: > On 03/04/2010 08:57 PM, Patrick Nagel wrote: >> Obviously, users who "re-install" Gentoo the way you do will have less >> difficulties resolving a circular dependency than those who are just >> following >> the guide and getting their first Gentoo experience. > > I think that the cups issue is probably worth mentioning in the > Handbook. Whether it is there by default or not lots of people get > burned by it. A little advanced warning would help. > > I think that at the very least following the handbooks to the letter > should never lead to an error. > > I think that a good argument can be made for or against having cups in > the desktop profile - this might actually be the sort of thing a > survey would be useful to address. > > I think that is separate from the circular dependency issue. As long > as we have an unresolved circular dependency I think cups should be > off the list. However, I'd be the first to agree that this is a > short-term solution. > > The problem is that we only have two long-term solutions so far: > > 1. A smarter package manager that can work through these dependencies > automatically. > > 2. Splitting packages like poppler that have these issues. > > Both of these need effort to address. #1 requires PM work, and #2 > requires an ongoing commitment to do more work to keep poppler working. > > Unless somebody can come up with a #3 at this point the most > constructive thing anybody can do is help out. A good place to start > would be to write up some patches to the handbook that clearly explain > how to deal with this problem. > > I'm not sure I agree with the poppler maintainers but they may have > reasons that aren't apparent to me and the fact is that it is a whole > lot easier to tell somebody how to maintain a package when I'm not the > one actually doing the work. Nothing gets results in FOSS like dirty > hands... > > Rich > > Well said. I agree with this. The devs may not be able to fix this specific issue but circular deps come up. We need a long term fix and now is as good a time as any to start thinking of one. Heck, I don't expect this to be done this week. It may take months to fix this or just figure out a way to do it. I just know this is becoming a problem and it isn't getting any better even tho people are trying. I would like to see a solution like happened with the blocks issue. Just some way that is easy for the devs to keep the tree clean but also have a package manager that can work around this. Even if it means portage spitting out a message that some packages shouldn't be used during the update because some packages have to be uninstalled first, that would be good. Let portage wait for a yes/no reply before doing the updates and doing them as close to first thing as possible. Read that as, don't compile openoffice then come back to the deps part. Progress. Dale :-) :-)