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 1S7Ii4-0001I2-GP for garchives@archives.gentoo.org; Tue, 13 Mar 2012 03:47:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DF45CE0B01; Tue, 13 Mar 2012 03:47:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 892CAE0AE7 for ; Tue, 13 Mar 2012 03:46:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E79E21B4006 for ; Tue, 13 Mar 2012 03:46:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5.5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_w5F0kKouAH for ; Tue, 13 Mar 2012 03:46:20 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 8BBFD677BF for ; Tue, 13 Mar 2012 03:46:20 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S7Igi-0004Ua-HW for gentoo-user@gentoo.org; Tue, 13 Mar 2012 04:46:16 +0100 Received: from athedsl-352089.home.otenet.gr ([85.72.230.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Mar 2012 04:46:16 +0100 Received: from realnc by athedsl-352089.home.otenet.gr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Mar 2012 04:46:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Nikos Chantziaras Subject: [gentoo-user] Re: virtual/shadow Date: Tue, 13 Mar 2012 05:46:00 +0200 Organization: Lucas Barks Message-ID: References: <1669924605.604523.1331575521916.JavaMail.open-xchange@email.1and1.com> <20120312222910.063104c6@khamul.example.com> <20120312173416.06817095@fuchsia.remarqs.net> <20120313002317.623e4e26@digimed.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: athedsl-352089.home.otenet.gr User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120302 Thunderbird/10.0.1 In-Reply-To: <20120313002317.623e4e26@digimed.co.uk> X-Archives-Salt: bcd158e7-66fe-49ae-b4c1-304d29468944 X-Archives-Hash: 68e630ba14a3edcdd21ed26c86d7f654 On 13/03/12 02:23, Neil Bothwick wrote: > On Tue, 13 Mar 2012 01:54:30 +0200, Nikos Chantziaras wrote: > >>>> Anyone care to offer an opinion on what it will take to get PROVIDES >>>> support in portage? >>> >>> IMO, it would take virtuals causing so many headachy breakages that >>> some devs started keeping up a steady drumbeat on irc and mailing >>> lists. When the number of virtual packages gets close to a thousand, >>> I'd guess that might happen. Then there would be years of discussion >>> and GLEP proposals, and by EAPI 207 it should be done. >> >> The problem isn't the amount of virtuals. This doesn't affect the >> users much. It's the inability for people to offer replacement >> packages in overlays. > > They could include a modified virtual in the overlay, but your point is > valid; including the information in the ebuilds is more flexible. This only works if portage has a virtual. If it doesn't, you're screwed. You need to also provide modified packages of all ebuilds depending on the package you're offering a replacement for. As you can guess, it's not practical. This leaves only one option; have users put the original package in package.provided and emerge your replacement as a non-dep (going in "world".)