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

[Michael Schreckenbauer <grimlog@gmx.de>]

On Tuesday, 13. September 2011 01:11:39 Nikos Chantziaras wrote:
> On 09/13/2011 12:18 AM, Michael Schreckenbauer wrote:
> > 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.
> 
> So is package.provided :-)

Of course :) Point is, you provide a package from the outside world, you tell 
that portage via package.provided. In the outside world, there is no slot. So 
you cannot provide 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?
> 
> Yes.  It should do exactly that.  Because of lack of information, it
> should assume that I know what I'm doing.
> 
> Fortunately, it does exactly that :-)  The original point of my post is
> why it works with "emerge foo-version" but not with "emerge foo:slot".

Yes, it does that. In my opinion, that behaviour is not correct.

I think, you are "abusing" package.provided for something, that should be 
handled by a local overlay with patched freetype-ebuilds.

Best,
Michael