From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4891 invoked from network); 19 Jun 2004 15:00:54 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Jun 2004 15:00:55 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BbhKv-0004UJ-1o for arch-gentoo-dev@lists.gentoo.org; Sat, 19 Jun 2004 15:00:53 +0000 Received: (qmail 9787 invoked by uid 89); 19 Jun 2004 15:00:52 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 21295 invoked from network); 19 Jun 2004 15:00:52 +0000 Message-ID: <33438.68.78.45.146.1087657251.squirrel@68.78.45.146> In-Reply-To: <200406192051.52265.jstubbs@gentoo.org> References: <200406192051.52265.jstubbs@gentoo.org> Date: Sat, 19 Jun 2004 11:00:51 -0400 (EDT) From: joe@neoturbine.net To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [gentoo-dev] Virtuals - required? X-Archives-Salt: 1e2aa74e-540b-47bf-9ea5-cbd3517f0913 X-Archives-Hash: 8b77c3d2502a4908dade2c84504eff0a > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I had another crazy idea that I'd like some feedback on. I'll jump > straight > in. With the current virtuals system, there are two basic deficiencies: > > 1. Packages that can provide a virtual based on USE flags can't. (#32114) > 2. Different versions of a virtual are not supported. (#46968) > > The proposal for 1 is to have PROVIDE use a syntax similar to DEPEND for > specifying any USE flag relationship. There is currently no proposal for > 2. > > What I'm proposing here is to drop virtuals altogether. Instead, I propose > using meta-packages similar to kde and gnome. To give a give a cut down > example: > > virtual/x11-1.ebuild: > RDEPEND="x86? ( || ( x11-base/xfree x11-base/xorg-x11 ) ) > sparc? ( || ( x11-base/xorg-x11 x11-base/xfree ) )" > > The -1 in x11-1 is an arbitrary version. This example shows the only > deficiency of doing it this way that I am able to think of. Instead of > specifying the default virtuals per profile, they would only be able to be > specified per architecture. > > Now to an example that shows a resolution to issue 2 above: > > virtual/jdk-1.4.ebuild: > RDEPEND="|| ( >=dev-java/blackdown-jdk-1.4 >=dev-java/kaffe-1.1.4 ... )" > > The different versions aspect is represented here by kaffe-1.1.4. Even it > is > installed it is presently not able to satisfy >=virtual/jdk-1.4 as its > version component does not match. :/ So, say I want my love-sources ebuild in my overlay to provide for virtual/winkernel (since some versions are patched with win4lin), Rather then editing the love-sources ebuild (which will survive an emerge sync), I have to edit this metaebuid for the virtual (which will not survive an emerge sync unless ) > As for issue number 1, it will require a (already scheduled) portage > enhancement: > > virtual/login-1.ebuild: > RDEPEND="|| sys-apps/shadow[pam] sys-apps/pam-login[-pam]" > > Here, shadow with USE="pam" or pam-login with USE="-pam" are supported. > > As a side note, a single atom is chosen || () dependencies. If something > installed satisfied any of the atoms, then the installed package is used. > Otherwise the first package in the list is used. > > Finally, there are two additional benefits. One is a slight speed increase > as > portage would no longer have to concern itself with virtuals. Second, is > that > it would be possible to find all packages that satisify a virtual without > scanning the entire tree for PROVIDEs. > > Do I burn in hell? (Again? ) >>From portage-*.51 /var/cache/edb/virtuals has been deprecated and is now calculated" on demand. Strictly _USER_ modifications to virtuals may go into" /etc/portage/virtuals and will never be modified by portage. It would sound like there is already work to change virtuals around, and i assume that "calculated on demand" is pretty much the opposite of your idea. -- gentoo-dev@gentoo.org mailing list