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 1MrKiT-00059C-NG for garchives@archives.gentoo.org; Sat, 26 Sep 2009 00:00:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3A819E041F; Sat, 26 Sep 2009 00:00:45 +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 145D1E041F for ; Sat, 26 Sep 2009 00:00:45 +0000 (UTC) Received: by qyk29 with SMTP id 29so2426957qyk.32 for ; Fri, 25 Sep 2009 17:00:44 -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:date:message-id:mime-version :x-mailer; bh=4xV6Wt0XW+4erI2tFap3iGpte6Q2lLwfwVqG7S6J5/M=; b=d/mBYdlmgXYMMdJduPI3lRALLJhY4PhdkLVbjDrg8ZfUzaseKClcBWeeCAvz2MK48N 8b3QlrDYTP+25Zw1QTxr/cBV8KYXb65/LnjxWhBaFngTZrK8Utq5uHJrv6XJXNyFIGvb WdbuQDzu8ivsmcigOJ4hJhBUXvclnwl2SkrgI= 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 :date:message-id:mime-version:x-mailer; b=JFJ/ski6gaCNIQqRgI7IEUoabApQNSRi5eyLkhLMv6Lqbkcb98BtiF1pQXbdBnqTVM YEM5mlk2ZcdBTV0v/PxK+KpXdWos5IRRjslvKZBk4tv9pPEPw8CDDYiCE+C31HmCIf6N 0Z7VvVvC7EZuK8OJdyq5ilTlndBAck8qANTbc= Received: by 10.224.29.130 with SMTP id q2mr929303qac.75.1253923244783; Fri, 25 Sep 2009 17:00:44 -0700 (PDT) Received: from ?190.203.164.97? ([190.203.164.97]) by mx.google.com with ESMTPS id 8sm472259qwj.4.2009.09.25.17.00.43 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Sep 2009 17:00:44 -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: Nikos Chantziaras Cc: gentoo-devhelp@lists.gentoo.org In-Reply-To: References: <4ABBD8C1.5040003@j-schmitz.net> <4ABCC70D.5030507@j-schmitz.net> <1253908146.6432.15.camel@linux-2anc.site> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-WlynXJxxRtXbUig3vF3U" Date: Fri, 25 Sep 2009 19:30:45 -0430 Message-Id: <1253923245.7405.2.camel@silversword> 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.26.3 X-Archives-Salt: 63161d43-ba68-4cfb-a537-84843c2eb249 X-Archives-Hash: 000502cb3295fffaa37f3e03a67f765b --=-WlynXJxxRtXbUig3vF3U Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El s=C3=A1b, 26-09-2009 a las 00:11 +0300, Nikos Chantziaras escribi=C3=B3: > On 09/25/2009 10:49 PM, Sebasti=C3=A1n Magr=C3=AD wrote: > > 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. > >>> > >>> I'm not sure how I can use virtuals to provide an alternative but > >>> completely compatible package. I'll give a straight example: > >>> > >>> 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). > >>> [...] > >> 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 on= e > >> in the tree. > > > > Why don't just use revision numbers? that's what I've always done... >=20 > Because if a higher version shows up in portage, it will be updated to=20 > that one. >=20 > The only thing that seems to help is to prefix it with an insanely high=20 > number, like "qt-opengl-99.4.5.2". However, this has the drawback that=20 > it only works for just one overlay. It's just a kludge. It's actually=20 > the same package, just a different version of it. The fundamental=20 > problem of being unable to provide* alternative packages that are easy=20 > to use by end users isn't solved. >=20 > * Note that the focus is on "provide" to others, not "use" myself. >=20 >=20 Then you will have to provide all the rdeps with alternative atom in depends I guess... Am I right? --=-WlynXJxxRtXbUig3vF3U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkq9Wa0ACgkQXk6IGbO9i1nBlQCcCFgLFUUU/Londs+FSNBPvc+s JjsAoJz4VFUB52ZA3/OGD5q34DBsult4 =ZrCF -----END PGP SIGNATURE----- --=-WlynXJxxRtXbUig3vF3U--