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

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

[Nikos Chantziaras]

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?

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

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Sep 12, 2011 11:11 PM, "Nikos Chantziaras" <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?

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.

(someone please CMIIW)

Rgds,

[-- Attachment #2: Type: text/html, Size: 1336 bytes --]

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

[Nikos Chantziaras]

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.

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

[Alan McKinnon]

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.

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



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Nikos Chantziaras]

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.

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

[Alan McKinnon]

On Mon, 12 Sep 2011 23:48:01 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> > 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.

I can't explain that (and reading the portage sources is not something
that fills me with joy).

I can think up a few possibilities ranging from the .provided code
predates slots and has never been touched since all the way up to there
being some real conflict you and I don't know about.


> 
> 
> > 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.

If portage tries to clobber a file you provided, then portage will see
it and collision-protect will do it's job. If you clobber an existing
file while installing something you provided, well that's your fault
and you should have paid attention. So I don't think the foo|bar
scenario you describe is anything worth worrying about. 

Maybe it really is just a case of "You provided xyz, you will
therefore provide everything about xyz, even slots". I know that's the
starting position I would take if I were Zac.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Michael Schreckenbauer]

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.

Regards,
Michael

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

[Nikos Chantziaras]

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.

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

[Michael Schreckenbauer]

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.

Best,
Michael

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

[Nikos Chantziaras]

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.

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

[Michael Schreckenbauer]

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.

Best,
Michael

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

[Nikos Chantziaras]

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.

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.

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

[Michael Schreckenbauer]

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

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

[Nikos Chantziaras]

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 :-)


>> 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".

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

[Michael Schreckenbauer]

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

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

[Nikos Chantziaras]

On 09/13/2011 01:26 AM, Michael Schreckenbauer wrote:
> On Tuesday, 13. September 2011 01:11:39 Nikos Chantziaras wrote:
>>> [...]
>>> 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.

I think Alan actually provided a more correct POV, namely that 
package.provided was never updated to consider slots.  If in the 
"outside world" there are no slots, then portage shouldn't have 
introduced that feature in the first place.  But it did, and the 
package.provided mechanism was never updated.


>>> 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.

I'm pretty sure you know very well by now that forking the portage tree 
isn't a Gentooer's idea of a great time ;-)  We use Gentoo's tools to 
their fullest in order to lower burden and overhead, not raise it.

Forking my own ebuild means I need to maintain it; forever and ever. 
And stuff like that will keep piling up over time, leading to a big, 
magnificent pile of unmaintainable mess, leading to a bad experience and 
the question of I use Gentoo in the first place if all it will give me 
is annoyance and stress.

On the other hand, if a single line in package.provided does the job 
just as well, oh hell, I'm going for that one instead.