Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
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
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
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
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
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. 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.mckin...@gmail.com
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Sep 13, 2011 2:10 AM, Nikos Chantziaras rea...@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,
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
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
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Mon, 12 Sep 2011 23:48:01 +0300 Nikos Chantziaras rea...@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.mckin...@gmail.com
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
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
