Bug 323331 – python-updater odd behaviors

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Paul Osmialowski 2010-06-09 14:03:36 UTC]

This is quite annoying: I am starting python-updater after every update of python interpreter. It causes number of packages to be re-emerged: small ones (like python libraries) and the biggest in whole system (like scratchbox, boost, openoffice). Since this is quite big number of packages, it is almost impossible to finish in one day. As I'm turning off the system for the night, I'm trying to restart this process with emerge --resume. This unfortunately, causes emerge run from the start, all the packages that were already re-emerged. So I was wondering what would happend when I run python-updater once again. Next run of python-updater picked only those biggest packages (smaller packages were already re-emergered and python-updater recognised it somehow). Problem is, that boost (two slotted versions!) and scratchbox were finished day before, so I expected that python-updater is able to figure out that only openoffice is to re-emerge now. Since on my Pentium 4 HT re-emerging slotted versions of boost can last all day, I guess python-updater will never succeed on this box.
On other hosts where I have boost, when I run python-updater to make sure everything is properly handled by python, boost is always re-emerged no matter how many times I run python-updater. How come this can be avoided for other libraries and applications?!


Reproducible: Always

Steps to Reproduce:
1. update python on system with boost (and/or scratchbox) installed
2. run python-updater
3. run python-updater once again

Actual Results:  
python-updater will always pick boost (and/or scratchbox) no matter how many times it will be started


Expected Results:  
all python-related packages should be re-emerged only once

[Comment 1 Michael Weber (RETIRED) 2010-06-09 14:11:50 UTC]

Rebooting the machine might wipe the tmp dir (/etc/conf.d/bootmisc) this might affect the `emerge --resume` behavior.
Have you tried to hibernate/suspend the machine?
You can continue an stopped emerge process of a single package by calling `ebuild /usr/portage/<cat>/<package>/<package with version>.ebuild install qmerge clean`.

I see this right that the emerge of the boots package never finished? If so, it's not strange that python-updater tries to emerge that again.

[Comment 2 Paul Osmialowski 2010-06-09 14:34:00 UTC]

(In reply to comment #1)
> Rebooting the machine might wipe the tmp dir (/etc/conf.d/bootmisc) this might
> affect the `emerge --resume` behavior.
> Have you tried to hibernate/suspend the machine?
Sounds reasonable, indeed it says WIPE_TMP="yes"

> You can continue an stopped emerge process of a single package by calling
> `ebuild /usr/portage/<cat>/<package>/<package with version>.ebuild install
> qmerge clean`.
> 
> I see this right that the emerge of the boots package never finished? If so,
> it's not strange that python-updater tries to emerge that again.
> 
No no no, boost finished, then openoffice started, and since it was late at night, I interupted that. I was expecting it will start from this point in the morning.
Also, on other gentoo boxes, boost is always picked by python-updater, so I wonder how come other python libraries typically picked on each major python updates are not re-emerged too?

[Comment 3 Michael Weber (RETIRED) 2010-06-09 15:39:31 UTC]

We have to straighten some things up here:

1) emerge --resume only works on a per package basis, it does not continue the compilation of single packages, it restarts them by resuming the whole emerge process (like an previos `emerge -avuND world`). 

2) To continue an stopped single package merge (`ebuild <atom> clean install qmerge clean`) you have to preserve the PORTAGE_TEMPDIR, which is /var/tmp/portage by default, usefull for __BIG__ emerges like openoffice (try using openoffice-bin ;-) )

3) Python updater has to be run because python modules get installed into /usr/lib64/python2.6/site-packages/ for example and if the minor version changes, they have to be rebuild into a python2.7 dir vor example. 

4) If python updater picks up a package that already had been re-emerged during this update-cycle (i assume 2.5 -> 2.6), than I would report this as an error.

5) You haven't provided the involded python versions, but do __NOT__ activate python3.1 as default, you sytem will badly breake, watch bug 313471 or bug 308257.

Michael

[Comment 4 Paul Osmialowski 2010-06-09 16:08:11 UTC]

(In reply to comment #3)
> 4) If python updater picks up a package that already had been re-emerged during
> this update-cycle (i assume 2.5 -> 2.6), than I would report this as an error.
> 
That's what I am talking about

> 5) You haven't provided the involded python versions, but do __NOT__ activate
> python3.1 as default, you sytem will badly breake, watch bug 313471 or bug
> 308257.
> 
I haven't provided involved python versions as I'm observing this for years now and this annoys me for some time. Now when I have gentoo on my desktop, bigger packages are involved (scratchbox, openoffice) so now this became a real problem. And don't worry, I have followed the advice from ebuild and didn't make python-3.x active.

[Comment 5 Arfrever Frehtes Taifersar Arahesis (RETIRED) 2010-06-09 18:22:36 UTC]

dev-libs/boost is broken, so python-updater hardcodes it in the list for "manual" check. You can disable this check.