Alan McKinnon wrote:
> There's an interesting conversation going on over at gentoo-dev about
> python-exec. One response I got is worthy of reposting here for anyone
> looking at all the python-exec updates and wondering what it's all
> about. The responder is mgorny:
>
>> One set of questions that were never answered and probably do deserve
>> some kind of notification:
> I can help you with these. However, I don't know on how much of it
> a random user cares.
>
>> 1. What exactly is python-exec anyway?
> It's the wrapper script that chooses the proper version of Python
> scripts for the currently selected Python version. Say, when you
> install 'foomatic' for p2.6, 2.7, 3.2 and 3.3, /usr/bin/foomatic is
> linked to python-exec and it determines which one to run.
>
>> 2. Why are there two, in dev-python/ and dev-lang/ ?
> The intent is that the one in dev-python/ was not slotted and the one
> in dev-lang/ is. This seems like the only sane way to support both
> slots without rewriting all the existing deps (which doesn't seem to
> work) or risking breaking the system.
>
>> 3. One has a version of -10000, which is *highly* unusual, what is that
>> exactly? 1 more than -9999?
> It is a plain virtual/compat/meta-package. It is a meaningless version
> that is supposed to be larger than anything that was earlier in
> dev-python/python-exec and it only pulls in dev-lang/python-exec.
>
>> 4. There is some kind of migration going on between an old and new
>> python-exec, but I can't understand it using only standard portage tools.
> Yes. The goal is that everything will dep on dev-lang/python-exec:=.
> However, we need to somehow keep things that deped on
> dev-python/python-exec in the past working.
>
>
>
> Posted in the hope some folks might find the answers useful.
>
>
I was doing my weekly update last night and ran into this:
[blocks B ] <dev-python/python-exec-10000
("<dev-python/python-exec-10000" is blocking dev-lang/python-exec-2.0,
dev-lang/python-exec-0.3.1)
and this little snippet:
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-libs/icu:0
(dev-libs/icu-51.1-r1::gentoo, ebuild scheduled for merge) pulled in by
dev-libs/icu:0/51.1= required by (media-libs/raptor-2.0.9::gentoo,
installed)
dev-libs/icu:0/51.1= required by (sys-apps/gptfdisk-0.8.6::gentoo,
installed)
>=dev-libs/icu-4.8.1.1:0/51.1= required by
(app-office/libreoffice-4.1.2.3::gentoo, installed)
dev-libs/icu:0/51.1= required by (media-libs/libcdr-0.0.14::gentoo,
installed)
dev-libs/icu:0/51.1= required by (app-text/libmspub-0.0.6::gentoo,
installed)
dev-libs/icu:0/51.1= required by
(media-libs/harfbuzz-0.9.12::gentoo, installed)
(dev-libs/icu-51.2-r1::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
app-text/poppler:0
(app-text/poppler-0.22.5::gentoo, installed) pulled in by
>=app-text/poppler-0.16:0/37=[xpdf-headers(+),cxx] required by
(app-office/libreoffice-4.1.2.3::gentoo, installed)
(app-text/poppler-0.24.3::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
It seems icu and popplar is at it again. I have had the chance to
unmerge python-exec and then trying to upgrade to see if it fixes the
block yet tho. Hopefully I will be able to try that in a little bit.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
