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 1R3Dvv-0002bt-LR for garchives@archives.gentoo.org; Mon, 12 Sep 2011 21:20:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5BBE121C0D4; Mon, 12 Sep 2011 21:20:37 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pigeon.gentoo.org (Postfix) with SMTP id 3FF0221C2FD for ; Mon, 12 Sep 2011 21:18:52 +0000 (UTC) Received: (qmail invoked by alias); 12 Sep 2011 21:18:50 -0000 Received: from p5B083DA8.dip.t-dialin.net (EHLO pc.localnet) [91.8.61.168] by mail.gmx.net (mp067) with SMTP; 12 Sep 2011 23:18:50 +0200 X-Authenticated: #13997268 X-Provags-ID: V01U2FsdGVkX1//XYZj4Qv/cUwfm1jfcCm5BhEWIOLz77GKd5lV75 JaxTxCk1bl760b From: Michael Schreckenbauer To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: package.provided messes up emerging of package slots? Date: Mon, 12 Sep 2011 23:18:45 +0200 Message-ID: <2997894.3Y8B7AYbSD@pc> User-Agent: KMail/4.7.1 (Linux/2.6.38-gentoo; KDE/4.7.1; x86_64; ; ) In-Reply-To: References: <2037937.Ts9Eii1Yvy@pc> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Y-GMX-Trusted: 0 X-Archives-Salt: X-Archives-Hash: e0513af6177ff01a1bc3c7308c2559cc On Monday, 12. September 2011 23:42:30 Nikos Chantziaras wrote: > On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote: > > On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote: > >> On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: > >>> On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: > >>>> On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: > >>>>> On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: > >>>>>> In my /etc/portage/profile/package.provided, I have this: > >>>>>> media-libs/freetype-1.4_pre20080316-r2 > >>>>>> > >>>>>> When I try to emerge freetype however, instead of emerging the > >>>>>> newer > >>>>>> > >>>>>> version, I get: > >>>>>> $ emerge freetype > >>>>>> > >>>>>> WARNING: A requested package will not be merged > >>>>>> because > >>>>>> it is > >>>>>> listed > >>>>>> > >>>>>> in package.provided: > >>>>>> freetype pulled in by 'args' > >>>>>> > >>>>>> Nothing to merge; would you like to auto-clean > >>>>>> packages? > >>>>>> [Yes/No] > >>>>>> > >>>>>> Trying "emerge freetype:2" also won't work. The only only to > >>>>>> emerge > >>>>>> it > >>>>>> seems is by using the whole version ("emerge > >>>>>> =freetype-2.4.6"). > >>>>>> Is > >>>>>> this > >>>>>> a bug? > >>>>> > >>>>> At least it's inconsistent. I would expect that the emerge with > >>>>> complete version also fails. > >>>> > >>>> It's slotted, so it shouldn't fail. Freetype 1 and 2 can be > >>>> installed > >>>> at the same time. > >>> > >>> Yes, that's true for the packages provided by portage. portage does > >>> not > >>> know anything about the freetype you provide, so it shouldn't > >>> install > >>> any freetype from any slot by any command. > >> > >> I don't see how it doesn't know anything about it, given that it > >> requires me to list a full package atom in package.provided. So it > >> always knows which version should be considered as being provided. > > > > Yes. freetype version 1. So if a package depends on freetype version 1, > > portage assumes, the dep is already installed. > > It does not know, where it is installed, or what files it installed. So > > it has to assume, that an emerge of freetype-2 actually could overwrite > > some of your freetype-1 files. Therefore it should not install > > freetype-2 with any command, if you have any version of freetype in > > package.provided. > > I disagree. A slotted package is practically two different packages > that simply share the same name. If one slot is assumed as being > provided, then that slot should have no effect on the other ones. You cannot provide a slot - you provide a package - freetype in this case. A slot is a gentoo specific thing. If you provide a package, you lose the advantages of portage. One of them being slots. > With your argument, portage should not install *any* packages at all if > there's even a single entry in package.provided, because it doesn't know > what that package installs and therefore *any other* package could > results in conflicts. Say, you had freetype-2.x in your package provided and for some reason you configured it to install to /usr/include/freetype, /usr/lib/freetype and so on. What should emerge do, if you now emerge freetype:1? Install it and overwrite your provided package? I only flipped versions here, because configuring freetype:1 to install to */freetype-2 sounds a bit strange :) If you tell portage "I care for freetype myself", then you have to deal with it. If you really need freetype:2 together with freetype:1, you have to provide freetype:2 also. Only you know, how to configure it, so it does not conflict with your freetype:1 Best, Michael