Re: [gentoo-dev] Python 2.7 status check?
On 11/30/10 03:24, Zac Medico wrote:
Yes, hopefully something like this will do it:
pkg_preinst() {
main_active_python=$(eselect python show)
}
pkg_postinst() {
if [[ -n $main_active_python
$main_active_python != $(eselect python show) ]] ; then
einfo restoring active python interpreter
eselect python set $main_active_python
fi
}
Intersting approach.
My debugging ebuild (attached) confirms a fitting order of invocations:
# sudo EMERGE_DEFAULT_OPTS= emerge -1 =virtual/debug-2.7.1 \
| fgrep STAGE
* STAGE pkg_setup (slot 2.7, version 2.7.1)
* STAGE src_unpack (slot 2.7, version 2.7.1)
* STAGE src_prepare (slot 2.7, version 2.7.1)
* STAGE src_configure (slot 2.7, version 2.7.1)
* STAGE src_compile (slot 2.7, version 2.7.1)
* STAGE src_install (slot 2.7, version 2.7.1)
* STAGE pkg_preinst (slot 2.7, version 2.7.1)
* STAGE pkg_prerm (version 2.7, slot 2.7)
* STAGE pkg_postrm (version 2.7, slot 2.7)
* STAGE pkg_postinst (slot 2.7, version 2.7.1)
Shall we give that approach a try?
One case it doesn't seem to catch though is when you just run
emerge -C dev-lang/python:X.Y
on a machine where Python X.Y was installed with eselect_python_update()
still in place. Correct?
Sebastian
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=2
inherit versionator
SLOT=$(get_version_component_range 1-2)
KEYWORDS=amd64
for stage in src_{unpack,prepare,configure,compile,install}
pkg_{config,setup,{pre,post}{inst,rm}} ; do
eval ${stage}'() {ewarn STAGE ${FUNCNAME} (slot ${SLOT}, version
${PV}) ; }'
done
Re: [gentoo-dev] Python 2.7 status check?
On 11/30/2010 08:26 AM, Sebastian Pipping wrote: * STAGE pkg_preinst (slot 2.7, version 2.7.1) * STAGE pkg_prerm (version 2.7, slot 2.7) * STAGE pkg_postrm (version 2.7, slot 2.7) * STAGE pkg_postinst (slot 2.7, version 2.7.1) Shall we give that approach a try? It seems like a reasonable approach. One case it doesn't seem to catch though is when you just run emerge -C dev-lang/python:X.Y on a machine where Python X.Y was installed with eselect_python_update() still in place. Correct? True, but that's not nearly as annoying as when it happens during a series of updates. -- Thanks, Zac
Re: [gentoo-dev] Python 2.7 status check?
On Tue, 30 Nov 2010 17:26:44 +0100 Sebastian Pipping sp...@gentoo.org wrote: My debugging ebuild (attached) confirms a fitting order of invocations: Careful with that. The order of pre/post stuff is package manager and EAPI dependent, thanks to Portage sneakily changing the order without telling anyone (and without checking existing ebuilds for breakage). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
pkg_preinst() {
main_active_python=$(eselect python show)
}
pkg_postinst() {
if [[ -n $main_active_python
$main_active_python != $(eselect python show) ]] ; then
einfo restoring active python interpreter
eselect python set $main_active_python
fi
}
I have combined your idea with Arfever's no-active-version-prevention
into the patch attached.
Anyone, please let me know if you consider it sane enough for applying
to all dev-lang/python ebuilds in Gentoo. Thanks!
Sebastian
From 8a6e0f532e469d851777c98a92fa09c2ae59489f Mon Sep 17 00:00:00 2001
From: Sebastian Pipping sebast...@pipping.org
Date: Tue, 30 Nov 2010 17:52:55 +0100
Subject: [PATCH] dev-lang/python: Apply combined restoring (zmedico) and repair
(arfrever) of active python version
---
dev-lang/python/Manifest|2 +-
dev-lang/python/python-2.7.1.ebuild | 38 +++
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/dev-lang/python/Manifest b/dev-lang/python/Manifest
index 9baa821..a068c28 100644
--- a/dev-lang/python/Manifest
+++ b/dev-lang/python/Manifest
@@ -25,7 +25,7 @@ EBUILD python-2.4.6.ebuild 8977 RMD160
38f346fc41002623b3b2b0a2b0b711bb7db7dd4e
EBUILD python-2.5.4-r4.ebuild 9327 RMD160
a6457b0ff606f4049cadeb9884cb4fe957b9958c SHA1
e747734e97cb520fb39f320f2c455b14b3ea0e6e SHA256
3bf309b7d68e56c45ace9d6967df8b534775593730ae5be67ce155f6b33d2bb0
EBUILD python-2.6.5-r3.ebuild 9122 RMD160
27044cab65202cfadfb8499b8a772fbfa52b1fc2 SHA1
ca3bdf0cf333de4d51fd7ac8a624ea97bf0cd00b SHA256
80c0fb7445edd89b371380f9aefdaeb4f4951aa5a534250e0ebbf8080dbba9d4
EBUILD python-2.6.6-r1.ebuild 9315 RMD160
35f711a57bb4947d791d7702097e907817d3d3cf SHA1
01bac9a202d9cde208c6812b3238c8e1cf4e8a02 SHA256
0920fb7e34be6cec6e0f7dc7bf1d63f9312293a95b6f1f74accdd443053c60ef
-EBUILD python-2.7.1.ebuild 10966 RMD160
7594d04f91503a6ae99cf4e6f322706f90dee217 SHA1
ed45a2db66c88b76c2b8cba260dc05fe91d2a2fb SHA256
3901a104673f155f4e35d9fee6f006d4655c688cfa7595aac83950b3d67446c0
+EBUILD python-2.7.1.ebuild 12114 RMD160
b53e6cfe32cfea5ed7f74183e4c66725284f8206 SHA1
a95c77665111d59d7dae83ae557d3966fcf3b42d SHA256
4fb4e52af3f2bc9a0a00d73fe922e92d32e071fce9228424ecc014cbd1d7de05
EBUILD python-2.7.ebuild 9425 RMD160 243ca80a7c4099fb0c06ababc461ef8bd1ad8417
SHA1 720f41cffb98b733fe242a415f43e575eb865a1f SHA256
dbb329d402907253537750ad2fa9c133037c9f4c28aa70c3720f5d21b2fdb3f1
EBUILD python-3.1.2-r4.ebuild 9215 RMD160
36e9ddbf18008b63653a3704c20e64e9f321c092 SHA1
33cb0ab09dd085b3a7724e9cc07ee630e13b6e6d SHA256
598c9199129f5b6efa9dc283f8d3de89428f034591365180f7a266fe2cce3d89
EBUILD python-3.1.3.ebuild 10398 RMD160
30ce48f92bf7796074e6410deca31ce9cc48e94a SHA1
4b68dbf85eb41c09e050c0f9ab54614ad43fa240 SHA256
2ed7457384281b818bacc6c904ccc24c032b0b7438ae7d625eb2c5f3c727bdec
diff --git a/dev-lang/python/python-2.7.1.ebuild
b/dev-lang/python/python-2.7.1.ebuild
index 4b8c34c..3d5a1fe 100644
--- a/dev-lang/python/python-2.7.1.ebuild
+++ b/dev-lang/python/python-2.7.1.ebuild
@@ -331,13 +331,49 @@ src_install() {
rmdir ${ED}$(python_get_libdir)/test/data
}
+save_active_python_version() {
+ active_python_2=$(eselect python show --python2)
+ active_python_3=$(eselect python show --python3)
+ active_python_main=$(eselect python show)
+}
+
pkg_preinst() {
+ save_active_python_version
+
if has_version ${CATEGORY}/${PN}-${SLOT} ! has_version
${CATEGORY}/${PN}:2.7; then
python_updater_warning=1
fi
}
+ensure_python_symlink() {
+ if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
+ eselect python update --python${PV%%.*}
+ fi
+}
+
+restore_active_python_version() {
+ if [[ -n ${active_python_2}
+ ${active_python_2} != $(eselect python show
--python2) ]] ; then
+ einfo Restoring active Python 2.x interpreter:
${active_python_2}
+ eselect python set ${active_python_2} --python2
+ fi
+ if [[ -n ${active_python_3}
+ ${active_python_3} != $(eselect python show
--python3) ]] ; then
+ einfo Restoring main active Python 3.x interpreter:
${active_python_3}
+ eselect python set ${active_python_3} --python3
+ fi
+
+ if [[ -n ${active_python_main}
+ ${active_python_main} != $(eselect python show) ]] ;
then
+ einfo Restoring main active Python interpreter:
${active_python_main}
+ eselect python set ${active_python_main}
+ fi
+}
+
pkg_postinst() {
+ restore_active_python_version
+ ensure_python_symlink
+
python_mod_optimize -f -x /(site-packages|test|tests)/
$(python_get_libdir)
if [[ ${python_updater_warning} == 1 ]]; then
@@ -354,5 +390,7 @@ pkg_postinst() {
}
pkg_postrm() {
+ ensure_python_symlink
+
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 16:47, Arfrever Frehtes Taifersar Arahesis wrote:
It wasn't any mistake. Please actually read that code:
eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}
${PV%%.*} == 2
'eselect python update --python2' would be called only if output of
'eselect python show --python2' was empty, which would occur when
there was no active version of Python 2 set (no /usr/bin/python2
symlink).
Thanks for that code. I apologize.
Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 02:35, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. But we still upgrade from 2.7 to 2.7.1 automatically, right? Cheers, Dirkjan
Re: [gentoo-dev] Python 2.7 status check?
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org writes: 2010-11-29 01:26:19 Robin H. Johnson napisał(a): Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. Worse than that, now python-updater is running it is removing all of the usr/lib/python-2.6/site-packages/ files and for multi-version aware packages only building for python-2.7 3.1, it is NOT building for python-2.6.
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 10:30, Graham Murray wrote: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org writes: 2010-11-29 01:26:19 Robin H. Johnson napisał(a): Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. I can confirm that unexpected behaviour. Just updating to 2.7.1 (and simultaneously 3.1.3, although that should be unrelated) switched to 2.7 as default, which I definitely did not ask for.
Re: [gentoo-dev] Python 2.7 status check?
On 29/11/10 10:36, Patrick Lauer wrote: On 11/29/10 10:30, Graham Murray wrote: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org writes: 2010-11-29 01:26:19 Robin H. Johnson napisał(a): Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. I can confirm that unexpected behaviour. +1 and I don't like that! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. The ebuilds you just added for 2.7.1 and 3.1.3 do contain eselect_python_update() and calls to it. I suppose that happened by mistake and removed eselect_python_update() on these ebuilds, too. They are in CVS now, mirrors take extra time. Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 10:07, Dirkjan Ochtman wrote: On Mon, Nov 29, 2010 at 02:35, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. But we still upgrade from 2.7 to 2.7.1 automatically, right? Yes, because that's the same slot (slot 2.7). Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 10:30, Graham Murray wrote: Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. Worse than that, now python-updater is running it is removing all of the usr/lib/python-2.6/site-packages/ files and for multi-version aware packages only building for python-2.7 3.1, it is NOT building for python-2.6. Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Best, Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 13:24, Paweł Hajdan, Jr. wrote: On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. Not that I knew. That's why I posted on Planet Gentoo recently: USE_PYTHON in /etc/make.conf http://blog.hartwork.org/?p=972 I'm aware it's no substitute. Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 01:38:11PM +0100, Sebastian Pipping wrote: On 11/29/10 13:24, Paweł Hajdan, Jr. wrote: On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. Not that I knew. That's why I posted on Planet Gentoo recently: USE_PYTHON in /etc/make.conf http://blog.hartwork.org/?p=972 I'm aware it's no substitute. Sebastian *sigh*, Planet is not a place to inform users about these things. How about a -dev-announce or even better a news item. Do you expect everyone to read planet or ML? News item is such a wonderful feature. Please please please use it. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpSFE5rsdRsO.pgp Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 1:42 PM, Markos Chandras wrote: *sigh*, Planet is not a place to inform users about these things. How about a -dev-announce or even better a news item. IMHO a news item is not much better. All users who install later than some date will not see the news item (by design). USE_PYTHON seems to be an important /etc/make.conf setting that is not documented. I think it should be added somewhere under http://www.gentoo.org/doc/en/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010 13:24:40 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. It shouldn't exist... The *correct* fix is to do it in a package manager aware way, for example by using slot operator dependencies that were supposed to be in EAPI 4. Horribly convoluted hacks and huge eclasses that exist primarily to bypass or reimplement things from the package manager cause more pain than they're worth. Does anyone remember the early days of webapp-config? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 13:42, Markos Chandras wrote: *sigh*, Planet is not a place to inform users about these things. How about a -dev-announce or even better a news item. Do you expect everyone to read planet or ML? News item is such a wonderful feature. Please please please use it. I did not invent it. I was pointed to it just a few weeks ago, noticed that it's little known and did a quick blog post about it. Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 12:43:40PM +0100, Sebastian Pipping wrote: On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote: Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. The ebuilds you just added for 2.7.1 and 3.1.3 do contain eselect_python_update() and calls to it. I suppose that happened by mistake and removed eselect_python_update() on these ebuilds, too. They are in CVS now, mirrors take extra time. Sebastian Revbump otherwise get ready for a series of bug reports from frustrated users -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpLYqhox42pZ.pgp Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
2010-11-29 12:43 Sebastian Pipping sp...@gentoo.org napisał(a):
On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote:
Sebastian Pipping recently removed automatic upgrade of active version of
Python, so
python-2.7.1.ebuild does not upgrade active version of Python.
The ebuilds you just added for 2.7.1 and 3.1.3 do contain
eselect_python_update() and calls to it.
I suppose that happened by mistake and removed eselect_python_update()
on these ebuilds, too. They are in CVS now, mirrors take extra time.
It wasn't any mistake. Please actually read that code:
eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}
${PV%%.*} == 2
'eselect python update --python2' would be called only if output of
'eselect python show --python2' was empty, which would occur when
there was no active version of Python 2 set (no /usr/bin/python2
symlink).
--
Arfrever Frehtes Taifersar Arahesis
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 04:47:36PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
2010-11-29 12:43 Sebastian Pipping sp...@gentoo.org napisał(a):
On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote:
Sebastian Pipping recently removed automatic upgrade of active version of
Python, so
python-2.7.1.ebuild does not upgrade active version of Python.
The ebuilds you just added for 2.7.1 and 3.1.3 do contain
eselect_python_update() and calls to it.
I suppose that happened by mistake and removed eselect_python_update()
on these ebuilds, too. They are in CVS now, mirrors take extra time.
It wasn't any mistake. Please actually read that code:
eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}
${PV%%.*} == 2
'eselect python update --python2' would be called only if output of
'eselect python show --python2' was empty, which would occur when
there was no active version of Python 2 set (no /usr/bin/python2
symlink).
--
Arfrever Frehtes Taifersar Arahesis
I updated two systems and they both switched to 2.7.1 automatically.
They were working fine with 2.6 before the update.
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpiaF7y7PtID.pgp
Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 16:37, Markos Chandras wrote: Revbump otherwise get ready for a series of bug reports from frustrated users I don't think this case qualifies for a revbump. The set of files produced is the same. The new revision offers nothing new to anyone having installed the previous revision. I intentionally did not bump the revision here. Am I missing something? Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 16:47, Arfrever Frehtes Taifersar Arahesis wrote:
It wasn't any mistake. Please actually read that code:
eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}
${PV%%.*} == 2
'eselect python update --python2' would be called only if output of
'eselect python show --python2' was empty, which would occur when
there was no active version of Python 2 set (no /usr/bin/python2
symlink).
Sounds logical. Any ideas how it bumped to 2.7.1 then? It seems it
happened to a few people.
Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 05:20:00PM +0100, Sebastian Pipping wrote: On 11/29/10 16:37, Markos Chandras wrote: Revbump otherwise get ready for a series of bug reports from frustrated users I don't think this case qualifies for a revbump. The set of files produced is the same. The new revision offers nothing new to anyone having installed the previous revision. I intentionally did not bump the revision here. Am I missing something? Sebastian The behavior of the package has changed though. Do not expect anyone who uses ~testing to know about eselect python module. If you are lucky enough, you will received just a few bug reports about this from those users who updated their packages before you fix the ebuilds. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgprzljF4mH72.pgp Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010, Alex Alexander wrote:
On Mon, Nov 29, 2010 at 04:47:36PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
It wasn't any mistake. Please actually read that code:
eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}
Unfortunately, that doesn't help at all. See below.
I updated two systems and they both switched to 2.7.1 automatically.
I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which
until two days ago unconditionally called the following eselect
action:
eselect python update --python2
So unless you had updated your python-2.6 during the last two days,
the installed version in your VDB would still contain the above line.
They were working fine with 2.6 before the update.
If it ain't broke, don't fix it? ;-)
Ulrich
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010, Markos Chandras wrote: Revbump otherwise get ready for a series of bug reports from frustrated users I don't think this case qualifies for a revbump. [...] The behavior of the package has changed though. Do not expect anyone who uses ~testing to know about eselect python module. If you are lucky enough, you will received just a few bug reports about this from those users who updated their packages before you fix the ebuilds. Also a revbump doesn't help if the bad code is in the old version's pkg_postrm(), which is installed on users' systems. Ulrich
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 17:31, Ulrich Mueller wrote: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: eselect python update --python2 So unless you had updated your python-2.6 during the last two days, the installed version in your VDB would still contain the above line. So a working fix would be to ripp out the update action? Do we still need that? Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/2010 08:43 AM, Sebastian Pipping wrote: On 11/29/10 17:31, Ulrich Mueller wrote: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: eselect python update --python2 So unless you had updated your python-2.6 during the last two days, the installed version in your VDB would still contain the above line. So a working fix would be to ripp out the update action? Do we still need that? You could also cancel it out, by checking the state in pkg_preinst and saving it in an environment variable so that you can restore it in pkg_postinst. -- Thanks, Zac
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller u...@gentoo.org writes: On Mon, 29 Nov 2010, Alex Alexander wrote: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: But as python-2.7 is installed into a new slot, python-2.6.x is kept, so python-2.6.6-r1's pkg_postrm() should not be called.
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller u...@gentoo.org writes: I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which until two days ago unconditionally called the following eselect action: But python-2.7 is installed in a new slot and python-2.6.x is not removed. So. surely python-2.6.6-r1's pkg_postrm() should not be called during the installation of python-2.7.1.
Re: [gentoo-dev] Python 2.7 status check?
On Mon, 29 Nov 2010, Graham Murray wrote:
I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which
until two days ago unconditionally called the following eselect
action:
But python-2.7 is installed in a new slot and python-2.6.x is not
removed. So. surely python-2.6.6-r1's pkg_postrm() should not be
called during the installation of python-2.7.1.
You are right, this cannot be the reason then.
But could pkg_postrm() of python-3.1.2-r4 have caused the update?
It essentially executed the following code:
[[ $(eselect python show) == python2.* ]]
eselect_python_options=--python2
eselect python update --python3 /dev/null
eselect python update ${eselect_python_options}
Ebuilds for 2.7.1 and 3.1.3 were committed together, and 3.1.2-r4 and
3.1.3 are in the same slot.
Ulrich
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller u...@gentoo.org writes: But could pkg_postrm() of python-3.1.2-r4 have caused the update? It essentially executed the following code: Yes, that is what is doing it. I am in the middle of an emerge -uD world and I ran 'eselect python list' after 2.7.1 had been emerged and it still showed 2.6 as being the active. But after 3.1.3 had been installed, it shows 2.7 as being the active version.
Re: [gentoo-dev] Python 2.7 status check?
On Mon, Nov 29, 2010 at 07:36:45PM +0100, Ulrich Mueller wrote:
On Mon, 29 Nov 2010, Graham Murray wrote:
I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which
until two days ago unconditionally called the following eselect
action:
But python-2.7 is installed in a new slot and python-2.6.x is not
removed. So. surely python-2.6.6-r1's pkg_postrm() should not be
called during the installation of python-2.7.1.
You are right, this cannot be the reason then.
But could pkg_postrm() of python-3.1.2-r4 have caused the update?
It essentially executed the following code:
[[ $(eselect python show) == python2.* ]]
eselect_python_options=--python2
eselect python update --python3 /dev/null
eselect python update ${eselect_python_options}
Ebuilds for 2.7.1 and 3.1.3 were committed together, and 3.1.2-r4 and
3.1.3 are in the same slot.
That's it. I ran those commands manually and the third one,
which evaluates to
eselect python update --python2
switched my python to 2.7.
On Mon, Nov 29, 2010 at 05:31:29PM +0100, Ulrich Mueller wrote:
On Mon, 29 Nov 2010, Alex Alexander wrote:
They were working fine with 2.6 before the update.
If it ain't broke, don't fix it? ;-)
I lol'd hard with this, thanks! :p
So, no updates at all? :D
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpittushruqq.pgp
Description: PGP signature
Re: [gentoo-dev] Python 2.7 status check?
Which basically means, it's time to simplify the eclass and start thinking how the abi details could be handled language-independent by portage. On Monday 29 November 2010 19:54:11 Graham Murray wrote: Ulrich Mueller u...@gentoo.org writes: But could pkg_postrm() of python-3.1.2-r4 have caused the update? It essentially executed the following code: Yes, that is what is doing it. I am in the middle of an emerge -uD world and I ran 'eselect python list' after 2.7.1 had been emerged and it still showed 2.6 as being the active. But after 3.1.3 had been installed, it shows 2.7 as being the active version. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, sunrise dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 18:33, Zac Medico wrote: You could also cancel it out, by checking the state in pkg_preinst and saving it in an environment variable so that you can restore it in pkg_postinst. Could you show a mockup of that? I'm not really sure how that would work. Would it work for pkg_postrm code of already installed packages? That would great to have. Thanks, Sebastian
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/2010 01:14 PM, Sebastian Pipping wrote:
On 11/29/10 18:33, Zac Medico wrote:
You could also cancel it out, by checking the state in pkg_preinst and
saving it in an environment variable so that you can restore it in
pkg_postinst.
Could you show a mockup of that?
I'm not really sure how that would work.
Would it work for pkg_postrm code of already installed packages?
That would great to have.
Yes, hopefully something like this will do it:
pkg_preinst() {
main_active_python=$(eselect python show)
}
pkg_postinst() {
if [[ -n $main_active_python
$main_active_python != $(eselect python show) ]] ; then
einfo restoring active python interpreter
eselect python set $main_active_python
fi
}
--
Thanks,
Zac
[gentoo-dev] Python 2.7 status check?
Presently in package.mask, we have this entry: # Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org (04 Jul 2010) # Python 2.7 masked until sufficient number of reverse dependencies is fixed. ~dev-lang/python-2.7 Well Python 2.7.1 was committed today, and does NOT match this mask, so are all of the reverse deps fixed? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Python 2.7 status check?
2010-11-29 01:26:19 Robin H. Johnson napisał(a): Presently in package.mask, we have this entry: # Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org (04 Jul 2010) # Python 2.7 masked until sufficient number of reverse dependencies is fixed. ~dev-lang/python-2.7 Well Python 2.7.1 was committed today, and does NOT match this mask, so are all of the reverse deps fixed? Sufficient number of reverse dependencies is fixed. Almost all remaining open bugs are about problems specific to test suites. Sebastian Pipping recently removed automatic upgrade of active version of Python, so python-2.7.1.ebuild does not upgrade active version of Python. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
