[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras <realnc@arcor.de>]

On 09/12/2011 11:31 PM, Alan McKinnon wrote:
> On Mon, 12 Sep 2011 19:49:28 +0300
> Nikos Chantziaras<realnc@arcor.de>  wrote:
>
>> On 09/12/2011 07:31 PM, Pandu Poluan wrote:
>>>
>>> On Sep 12, 2011 11:11 PM, "Nikos Chantziaras"<realnc@arcor.de
>>> <mailto:realnc@arcor.de>>  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?
>>>
>>> Why did you have that line in package.provided, in the first place?
>>> Did you install freetype on your own, without using portage?
>>
>> Portage installs both freetype-1 as well as freetype-2.  texlive has
>> freetype-1 as a dep, and I don't want it installed because I'm not
>> using ttf2tfm.
>>
>>
>>> The way I see it, Portage worked perfectly: it saw that you have
>>> installed a certain version of freetype on your own, and it didn't
>>> want to mess up your installed package.
>>>
>>> Just delete the line and emerge freetype.
>>
>>    From my point of view, it doesn't work perfectly, because it behaves
>> differently when freetype-1 is really installed, and when it's not
>> but listed in package.provided.  If I install freetype-1 and type:
>>
>>     emerge freetype
>>
>> it will emerge freetype:2.  So the behavior is vastly different
>> between having freetype really installed, and when not but listed in
>> package.provided.
>
>
> That's because a package being installed and being provided are not the
> same thing and are treated very differently.
>
> If you install xyz-1.2.3 then portage knows what it did to achieve
> that and can deal with it as normal.
>
> If you provide xyz-1.2.3 then portage does not know what *you* did to
> achieve that and makes no attempt to deal with it at all. You are
> expected to completely 100% deal with all of xyz, including all slots.
> "man 5 portage" mentions that the version number is there in
> package.provided so that portage can alert you if some other package
> has a dep on a version of xyz you did not provide.

Yes, on a *version*, not on a *slot*, which is in effect a different 
package but simply using the same name.


> Seen in that light, the behaviour is indeed sensible, just not
> consistent if you haven't read the docs yet. I don't think it's wise to
> try and change portage's behaviour with this, as Michael said in
> another sub-thread portage has no idea what you did so it can't even
> try to take control of different slots for fear it might clobber all
> your manual hard work

As I mentioned in my other post, portage should stop working altogether 
then, because conflicts can arise with any other package.  But portage 
*does* allows me to install package "foo" if I have "bar-1.0" listed in 
package.provided.  For the same reason, it should allow me install 
"foo:2" if I have a "foo" in package.provided that belongs to the 
"foo:1" slot.