* [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 16:31 ` Pandu Poluan
@ 2011-09-12 16:49 ` Nikos Chantziaras
2011-09-12 20:31 ` Alan McKinnon
0 siblings, 1 reply; 14+ messages in thread
From: Nikos Chantziaras @ 2011-09-12 16:49 UTC (permalink / raw
To: gentoo-user
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 16:42 ` [gentoo-user] " Michael Schreckenbauer
@ 2011-09-12 17:04 ` Nikos Chantziaras
2011-09-12 17:17 ` Michael Schreckenbauer
0 siblings, 1 reply; 14+ messages in thread
From: Nikos Chantziaras @ 2011-09-12 17:04 UTC (permalink / raw
To: gentoo-user
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 17:04 ` [gentoo-user] " Nikos Chantziaras
@ 2011-09-12 17:17 ` Michael Schreckenbauer
2011-09-12 18:31 ` Nikos Chantziaras
0 siblings, 1 reply; 14+ messages in thread
From: Michael Schreckenbauer @ 2011-09-12 17:17 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 17:17 ` Michael Schreckenbauer
@ 2011-09-12 18:31 ` Nikos Chantziaras
2011-09-12 19:02 ` Michael Schreckenbauer
0 siblings, 1 reply; 14+ messages in thread
From: Nikos Chantziaras @ 2011-09-12 18:31 UTC (permalink / raw
To: gentoo-user
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 18:31 ` Nikos Chantziaras
@ 2011-09-12 19:02 ` Michael Schreckenbauer
2011-09-12 20:42 ` Nikos Chantziaras
0 siblings, 1 reply; 14+ messages in thread
From: Michael Schreckenbauer @ 2011-09-12 19:02 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 16:49 ` [gentoo-user] " Nikos Chantziaras
@ 2011-09-12 20:31 ` Alan McKinnon
2011-09-12 20:48 ` Nikos Chantziaras
0 siblings, 1 reply; 14+ messages in thread
From: Alan McKinnon @ 2011-09-12 20:31 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 19:02 ` Michael Schreckenbauer
@ 2011-09-12 20:42 ` Nikos Chantziaras
2011-09-12 21:18 ` Michael Schreckenbauer
0 siblings, 1 reply; 14+ messages in thread
From: Nikos Chantziaras @ 2011-09-12 20:42 UTC (permalink / raw
To: gentoo-user
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 20:31 ` Alan McKinnon
@ 2011-09-12 20:48 ` Nikos Chantziaras
2011-09-12 21:18 ` Alan McKinnon
0 siblings, 1 reply; 14+ messages in thread
From: Nikos Chantziaras @ 2011-09-12 20:48 UTC (permalink / raw
To: gentoo-user
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
@ 2011-09-12 20:49 Pandu Poluan
0 siblings, 0 replies; 14+ messages in thread
From: Pandu Poluan @ 2011-09-12 20:49 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]
On Sep 13, 2011 2:10 AM, "Nikos Chantziaras" <realnc@arcor.de> 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.
>
Well, Portage in your case only knows 'which' version is provided so
packages that depend on that version can be emerged.
But, Portage has no knowledge of the 'provided' package's files (e.g., no
data about the package in /var/db) since listing a package in
package.provided implies the package is not managed by Portage. This means,
Portage can't do anything to the 'provided' package.
Rgds,
[-- Attachment #2: Type: text/html, Size: 3045 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 20:48 ` Nikos Chantziaras
@ 2011-09-12 21:18 ` Alan McKinnon
0 siblings, 0 replies; 14+ messages in thread
From: Alan McKinnon @ 2011-09-12 21:18 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 20:42 ` Nikos Chantziaras
@ 2011-09-12 21:18 ` Michael Schreckenbauer
2011-09-12 22:11 ` Nikos Chantziaras
0 siblings, 1 reply; 14+ messages in thread
From: Michael Schreckenbauer @ 2011-09-12 21:18 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 21:18 ` Michael Schreckenbauer
@ 2011-09-12 22:11 ` Nikos Chantziaras
2011-09-12 22:26 ` Michael Schreckenbauer
0 siblings, 1 reply; 14+ messages in thread
From: Nikos Chantziaras @ 2011-09-12 22:11 UTC (permalink / raw
To: gentoo-user
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".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 22:11 ` Nikos Chantziaras
@ 2011-09-12 22:26 ` Michael Schreckenbauer
2011-09-12 23:17 ` Nikos Chantziaras
0 siblings, 1 reply; 14+ messages in thread
From: Michael Schreckenbauer @ 2011-09-12 22:26 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-user] Re: package.provided messes up emerging of package slots?
2011-09-12 22:26 ` Michael Schreckenbauer
@ 2011-09-12 23:17 ` Nikos Chantziaras
0 siblings, 0 replies; 14+ messages in thread
From: Nikos Chantziaras @ 2011-09-12 23:17 UTC (permalink / raw
To: gentoo-user
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-09-12 23:20 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-12 20:49 [gentoo-user] Re: package.provided messes up emerging of package slots? Pandu Poluan
-- strict thread matches above, loose matches on Subject: below --
2011-09-12 15:41 [gentoo-user] " Nikos Chantziaras
2011-09-12 16:31 ` Pandu Poluan
2011-09-12 16:49 ` [gentoo-user] " Nikos Chantziaras
2011-09-12 20:31 ` Alan McKinnon
2011-09-12 20:48 ` Nikos Chantziaras
2011-09-12 21:18 ` Alan McKinnon
2011-09-12 16:42 ` [gentoo-user] " Michael Schreckenbauer
2011-09-12 17:04 ` [gentoo-user] " Nikos Chantziaras
2011-09-12 17:17 ` Michael Schreckenbauer
2011-09-12 18:31 ` Nikos Chantziaras
2011-09-12 19:02 ` Michael Schreckenbauer
2011-09-12 20:42 ` Nikos Chantziaras
2011-09-12 21:18 ` Michael Schreckenbauer
2011-09-12 22:11 ` Nikos Chantziaras
2011-09-12 22:26 ` Michael Schreckenbauer
2011-09-12 23:17 ` Nikos Chantziaras
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox