On 09/12/2011 11:31 PM, Alan McKinnon wrote:
On Mon, 12 Sep 2011 19:49:28 +0300
Nikos Chantziaras<rea...@arcor.de> wrote:
On 09/12/2011 07:31 PM, Pandu Poluan wrote:
On Sep 12, 2011 11:11 PM, "Nikos Chantziaras"<rea...@arcor.de
<mailto:rea...@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.
