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 1MrHaz-00024c-GA for garchives@archives.gentoo.org; Fri, 25 Sep 2009 20:40:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B766DE0684; Fri, 25 Sep 2009 20:40:48 +0000 (UTC) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by pigeon.gentoo.org (Postfix) with ESMTP id 9ADD4E0684 for ; Fri, 25 Sep 2009 20:40:48 +0000 (UTC) Received: by qyk29 with SMTP id 29so2334093qyk.32 for ; Fri, 25 Sep 2009 13:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:organization:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=KZ3NJbUcqHsxVvMSGdyqENJoTF0xGeCqIrlg+IQJBBU=; b=KVx2kpCIATr1hUB61rtmLPu4m0cmfqigiuL2XSl/F2HKHtJJgXsVw1ZVKBXiq2FjPB 0uj7kJqSnFQ8oW+gVJ/RZRLCOFNqNtpMMGjLFYWsYR//DD8oR+JjQL22lXhgvtzxr3Zs upiQLLZhyJvwVf6E+B09QsqV6vVBM7snCCVQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :organization:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=un8mQiPgDPy+35ZdzB+1WxX6MMYXJuGHa/LPs/ww6Y4Ts1JR/JJIVDuV7N6dimuHz8 p/kt+IHarC8/w+WL/vV4VcUztG5rP4UBsd/0WNt3Ubp3eDZKZ5TBaOL0NfYWwvJEu9VD wIbWytElr8s7wo3LnAmI6jXQaL93tQHrcO55U= Received: by 10.224.111.141 with SMTP id s13mr765058qap.146.1253911247961; Fri, 25 Sep 2009 13:40:47 -0700 (PDT) Received: from ?190.205.25.172? ([190.205.25.172]) by mx.google.com with ESMTPS id 20sm1439517qyk.13.2009.09.25.13.40.45 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Sep 2009 13:40:47 -0700 (PDT) Subject: Re: [gentoo-devhelp] Re: Writing ebuilds that replace others but with different name From: =?ISO-8859-1?Q?Sebasti=E1n_Magr=ED?= To: Justin Cc: gentoo-devhelp@lists.gentoo.org In-Reply-To: <4ABCC70D.5030507@j-schmitz.net> References: <4ABBD8C1.5040003@j-schmitz.net> <4ABCC70D.5030507@j-schmitz.net> Content-Type: text/plain; charset="UTF-8" Organization: sebasmagri Date: Fri, 25 Sep 2009 15:19:06 -0430 Message-Id: <1253908146.6432.15.camel@linux-2anc.site> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Development-related help X-BeenThere: gentoo-devhelp@gentoo.org X-BeenThere: gentoo-devhelp@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b526ce9e-6285-44e0-a491-1baa518471d3 X-Archives-Hash: 400abd102e0051337fccadb0c1d7e8a8 El vie, 25-09-2009 a las 15:35 +0200, Justin escribi=C3=B3: > Nikos Chantziaras schrieb: > > On 09/24/2009 11:38 PM, Justin wrote: > >> Nikos Chantziaras wrote: > >>> I seem to have some fundamental "flaw" in portage. It seems I am n= ot > >>> able to write an ebuild that will in effect be able to replace anot= her > >>> one but with a different name. > >>> > >>> With RPMs, no matter how the RPM is named, it has "provides" data i= n it. > >>> Is there some similar mechanism in portage? It seems to me that = if > >>> the > >>> name of an ebuild is changed, then *all* ebuilds depending on it wi= ll > >>> have to change too. That looks like a PITA to me if it's true. > >>> > >>> For example, if I have an overlay that provides alternative/altered > >>> packages of already existing ones in the portage tree, they will "c= lash" > >>> with portage. Let's assume that my overlay provides an ebuild call= ed > >>> "foo-alt" which is a variation of a package in portage called "foo"= , but > >>> is totally compatible with it. What I'm looking for is being able = to > >>> emerge "foo-alt", but have the ebuild state clearly that it provide= s the > >>> "foo" dependency, so ebuilds depending on "foo" will be satisfied i= f > >>> "foo-alt" is installed but "foo" isn't. > >>> > >>> Possible? > >>> > >>> > >> Thats's what virtuals are good for. As an example see virtual/jre. > >> But in principle you are right. renaming a package is a headache and > >> should really be avoided. > >=20 > > I'm not sure how I can use virtuals to provide an alternative but > > completely compatible package. I'll give a straight example: > >=20 > > In my overlay, there's "x11-libs/qt-opengl-alt". It is a variation o= f > > qt-opengl, providing and *replacing* all files in it. However, if I > > unmerge qt-opengl and install qt-opengl-alt instead, even though the > > installed packages depending on qt-opengl work perfectly fine with it > > (it's fully compatible), an "emerge -uDN world" will try to pull > > qt-opengl back in because it thinks it's missing (and this will of > > course result in a file collision since qt-opengl-alt is also install= ed, > > providing the same files). > >=20 > > Changing the category also doesn't help ("x11-libs-alt/qt-opengl" for > > example). > >=20 > > So virtuals don't seem to have anything to do with with my problem. > > What's missing is something like RPM's "provides" (so the qt-opengl-a= lt > > ebuild would be able to say "I provide the qt-opengl package.) From > > your answer, I take it that portage doesn't offer anything like this = and > > the ebuild's name is hardcoded to be the package it provides :P > >=20 > >=20 > Thats right, the only thing what you can do, is naming your ebuild > x11-libs/qt-opengl as well and give it higher version number as the one > in the tree. >=20 Why don't just use revision numbers? that's what I've always done...