| 1 |
On Sep 13, 2011 2:10 AM, "Nikos Chantziaras" <realnc@×××××.de> wrote: |
| 2 |
> |
| 3 |
> On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: |
| 4 |
>> |
| 5 |
>> On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: |
| 6 |
>>> |
| 7 |
>>> On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: |
| 8 |
>>>> |
| 9 |
>>>> On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: |
| 10 |
>>>>> |
| 11 |
>>>>> In my /etc/portage/profile/package.provided, I have this: |
| 12 |
>>>>> media-libs/freetype-1.4_pre20080316-r2 |
| 13 |
>>>>> |
| 14 |
>>>>> When I try to emerge freetype however, instead of emerging the newer |
| 15 |
>>>>> |
| 16 |
>>>>> version, I get: |
| 17 |
>>>>> $ emerge freetype |
| 18 |
>>>>> |
| 19 |
>>>>> WARNING: A requested package will not be merged because it is |
| 20 |
>>>>> listed |
| 21 |
>>>>> |
| 22 |
>>>>> in package.provided: |
| 23 |
>>>>> freetype pulled in by 'args' |
| 24 |
>>>>> |
| 25 |
>>>>> Nothing to merge; would you like to auto-clean packages? |
| 26 |
>>>>> [Yes/No] |
| 27 |
>>>>> |
| 28 |
>>>>> Trying "emerge freetype:2" also won't work. The only only to emerge |
| 29 |
>>>>> it |
| 30 |
>>>>> seems is by using the whole version ("emerge =freetype-2.4.6"). Is |
| 31 |
>>>>> this |
| 32 |
>>>>> a bug? |
| 33 |
>>>> |
| 34 |
>>>> |
| 35 |
>>>> At least it's inconsistent. I would expect that the emerge with |
| 36 |
complete |
| 37 |
>>>> version also fails. |
| 38 |
>>> |
| 39 |
>>> |
| 40 |
>>> It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed |
| 41 |
>>> at the same time. |
| 42 |
>> |
| 43 |
>> |
| 44 |
>> Yes, that's true for the packages provided by portage. portage does not |
| 45 |
know |
| 46 |
>> anything about the freetype you provide, so it shouldn't install any |
| 47 |
freetype |
| 48 |
>> from any slot by any command. |
| 49 |
> |
| 50 |
> |
| 51 |
> I don't see how it doesn't know anything about it, given that it requires |
| 52 |
me to list a full package atom in package.provided. So it always knows |
| 53 |
which version should be considered as being provided. |
| 54 |
> |
| 55 |
|
| 56 |
Well, Portage in your case only knows 'which' version is provided so |
| 57 |
packages that depend on that version can be emerged. |
| 58 |
|
| 59 |
But, Portage has no knowledge of the 'provided' package's files (e.g., no |
| 60 |
data about the package in /var/db) since listing a package in |
| 61 |
package.provided implies the package is not managed by Portage. This means, |
| 62 |
Portage can't do anything to the 'provided' package. |
| 63 |
|
| 64 |
Rgds, |
Archives