[gentoo-user] did python-r1 improve user experience?

[gentoo-user] did python-r1 improve user experience?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Since I maintain blender I have come across quite a few frustrated
users already: https://bugs.gentoo.org/show_bug.cgi?id=488976#c7

I am not sure myself. On one hand we don't need python-updater anymore
and have very tight dependencies that ensure that all needed modules
are always available for the desired implementation.

On the other hand it seems to give a lot of users trouble with
blockers, general configuration and mass-updates on things like
removing python:2.5.

What are your opinions? Did it improve user experience? What could be
improved?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSZ8uCAAoJEFpvPKfnPDWzeTgIAJeEatL7aJwIno1UVtkG11H4
DQpi3ofByswXWyCB8NjFJrKg5gxujnVnHqO30828C7RcIA0aR86BDsmI8RZHjRW5
9g7flVqLqxbMveCTzqM6EfZAzL449lcBCvXFkigbzO6Tkr5uqp6yzNe1BBqbUk2R
NCGbQt2czpztWulPb3HUKtLKegRH3l7sW4mTZY8wQ0dz7YH9fo7JV/Khy4vRi+lh
yj9Tks7R4o9vL8qmd72OqW8qF9L7uwudfER2jjRKKXBLYuRZv6GqjdTE9uTQtRwV
hPG9fyKbzTKaYdN4CUy7bJoWTD5/+VoMQ8MXfrQjG83R5klD7u3X/pPmDJHTt3E=
=f3kj
-----END PGP SIGNATURE-----

Re: [gentoo-user] did python-r1 improve user experience?

[Mike Gilbert]

On Wed, Oct 23, 2013 at 9:13 AM, hasufell <hasufell@gentoo.org> wrote:
> Since I maintain blender I have come across quite a few frustrated
> users already: https://bugs.gentoo.org/show_bug.cgi?id=488976#c7
>
> I am not sure myself. On one hand we don't need python-updater anymore
> and have very tight dependencies that ensure that all needed modules
> are always available for the desired implementation.
>
> On the other hand it seems to give a lot of users trouble with
> blockers, general configuration and mass-updates on things like
> removing python:2.5.
>
> What are your opinions? Did it improve user experience? What could be
> improved?

As one of the lead devs on the python team, here are my thoughts.

I think we have made things more "correct". As a developer, it is much
easier for me to tell when a package has incomplete or simply broken
python dependencies.

On the user side, I think we have traded occasional/random build
failures due to mismatched python versions for some barely
comprehensible portage dependency conflict messages. This is certainly
not ideal, but I think it is always better to have portage fail during
dependency resolution than at build time.

The (non-)relationship between eselect python and PYTHON_TARGETS is
something that would be nice to resolve, but I don't know how to do
it. PYTHON_SINGLE_TARGET will probably cause problems if/when packages
start supporting python3 only.

Re: [gentoo-user] did python-r1 improve user experience?

[Walter Dnes]

On Sat, Oct 26, 2013 at 09:30:57PM -0400, Mike Gilbert wrote

> The (non-)relationship between eselect python and PYTHON_TARGETS is
> something that would be nice to resolve, but I don't know how to do
> it. PYTHON_SINGLE_TARGET will probably cause problems if/when packages
> start supporting python3 only.

  What I find interesting/annoying is that my make.conf has to have 3
lines...

PYTHON_SINGLE_TARGET="python2_7"
PYTHON_TARGETS="python2_7"
USE_PYTHON="2.7"

...as if it didn't hear me the first time.  How difficult would it be to
set up an eclass to tell portage that...

if PYTHON_SINGLE_TARGET="pythonX_Y"

PYTHON_TARGETS defaults to "${PYTHON_SINGLE_TARGET}"

USE_PYTHON defaults to "${PYTHON_SINGLE_TARGET/_/.}"

  Over-ride the default if explicitly listed.  Out of sheer curiousity,
what circumstances are there where ordinary users would need differing
values for these 3 items?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] did python-r1 improve user experience?

[Bruce Hill]

On Sat, Oct 26, 2013 at 10:18:11PM -0400, Walter Dnes wrote:
> On Sat, Oct 26, 2013 at 09:30:57PM -0400, Mike Gilbert wrote
> 
> > The (non-)relationship between eselect python and PYTHON_TARGETS is
> > something that would be nice to resolve, but I don't know how to do
> > it. PYTHON_SINGLE_TARGET will probably cause problems if/when packages
> > start supporting python3 only.
> 
>   What I find interesting/annoying is that my make.conf has to have 3
> lines...
> 
> PYTHON_SINGLE_TARGET="python2_7"
> PYTHON_TARGETS="python2_7"
> USE_PYTHON="2.7"
> 
> ...as if it didn't hear me the first time.  How difficult would it be to
> set up an eclass to tell portage that...
> 
> if PYTHON_SINGLE_TARGET="pythonX_Y"
> 
> PYTHON_TARGETS defaults to "${PYTHON_SINGLE_TARGET}"
> 
> USE_PYTHON defaults to "${PYTHON_SINGLE_TARGET/_/.}"
> 
>   Over-ride the default if explicitly listed.  Out of sheer curiousity,
> what circumstances are there where ordinary users would need differing
> values for these 3 items?

Mine only have PYTHON_TARGETS="python2_7" and I unmerge python3 immediately
after install.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] did python-r1 improve user experience?

[Mike Gilbert]

On Sat, Oct 26, 2013 at 10:18 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Oct 26, 2013 at 09:30:57PM -0400, Mike Gilbert wrote
>
>> The (non-)relationship between eselect python and PYTHON_TARGETS is
>> something that would be nice to resolve, but I don't know how to do
>> it. PYTHON_SINGLE_TARGET will probably cause problems if/when packages
>> start supporting python3 only.
>
>   What I find interesting/annoying is that my make.conf has to have 3
> lines...
>
> PYTHON_SINGLE_TARGET="python2_7"
> PYTHON_TARGETS="python2_7"
> USE_PYTHON="2.7"
>
> ...as if it didn't hear me the first time.  How difficult would it be to
> set up an eclass to tell portage that...
>
> if PYTHON_SINGLE_TARGET="pythonX_Y"
>
> PYTHON_TARGETS defaults to "${PYTHON_SINGLE_TARGET}"
>
> USE_PYTHON defaults to "${PYTHON_SINGLE_TARGET/_/.}"
>
>   Over-ride the default if explicitly listed.  Out of sheer curiousity,
> what circumstances are there where ordinary users would need differing
> values for these 3 items?
>

PYTHON_TARGETS and PYTHON_SINGLE_TARGET are used indirectly by
python-r1.eclass. However, both are both expanded into use flags and
used in dependency calculations before any ebuild/eclass code is
invoked. So, we cannot manipulate them in an eclass or ebuild.

PYTHON_TARGETS may contain multiple python versions and is used for
most python packages in the tree. It allows the same package to be
installed for multiple python versions simultaneously.

PYTHON_SINGLE_TARGET should only contain one python version; it is
used for packages which cannot (easily) be made to support multiple
versions of python simultaneously. So we have to pick one.

USE_PYTHON is a legacy setting used by the old python.eclass and is
not used to control any use flags or dependencies. Ideally, we could
default this to PYTHON_TARGETS, but due to the way use-expanded
variables work this is not possible. This variable will go away once
python.eclass is removed from the portage tree.

Re: [gentoo-user] did python-r1 improve user experience?

[William Kenworthy]

On 27/10/13 09:30, Mike Gilbert wrote:
> On Wed, Oct 23, 2013 at 9:13 AM, hasufell <hasufell@gentoo.org> wrote:
>> Since I maintain blender I have come across quite a few frustrated
>> users already: https://bugs.gentoo.org/show_bug.cgi?id=488976#c7
>>
>> I am not sure myself. On one hand we don't need python-updater anymore
>> and have very tight dependencies that ensure that all needed modules
>> are always available for the desired implementation.
>>
>> On the other hand it seems to give a lot of users trouble with
>> blockers, general configuration and mass-updates on things like
>> removing python:2.5.
>>
>> What are your opinions? Did it improve user experience? What could be
>> improved?
> 
...

The python user experience is less than overwhelming for a user.

1. if python-update is no longer needed (first I have heard of this) why
is it still rebuilding many packages after an upgrade ...

2. I have python 2.7 installed and python 3.x is being asked to be
installed ... isnt that enough? - shorely it can work out what it needs
from whats been asked for/removed and whats already on the system ...
instead we need to add these cryptic, poorly explained lines that one
only finds out from emails etc.  The elog message for the one exception
asks that the line be added to make.conf without telling the user what
happens if he upgrades later (as it lists specific versions) or makes
changes - does that line have any effect, especially if he makes a
mistake (which I did and I am not sure what it did in the background)?

4. sorry if the above sounds over the top but some of the changes did go
wrong for me ... as is the grub2 upgrade I am still trying to get to
work after many hours ...

5. and I am really really impressed that a dev has actually asked the
users ... unlike other decisions being made!

BillK

Re: [gentoo-user] did python-r1 improve user experience?

[Mike Gilbert]

On Sat, Oct 26, 2013 at 11:41 PM, William Kenworthy <billk@iinet.net.au> wrote:
> On 27/10/13 09:30, Mike Gilbert wrote:
>> On Wed, Oct 23, 2013 at 9:13 AM, hasufell <hasufell@gentoo.org> wrote:
>>> Since I maintain blender I have come across quite a few frustrated
>>> users already: https://bugs.gentoo.org/show_bug.cgi?id=488976#c7
>>>
>>> I am not sure myself. On one hand we don't need python-updater anymore
>>> and have very tight dependencies that ensure that all needed modules
>>> are always available for the desired implementation.
>>>
>>> On the other hand it seems to give a lot of users trouble with
>>> blockers, general configuration and mass-updates on things like
>>> removing python:2.5.
>>>
>>> What are your opinions? Did it improve user experience? What could be
>>> improved?
>>
> ...
>
> The python user experience is less than overwhelming for a user.
>
> 1. if python-update is no longer needed (first I have heard of this) why
> is it still rebuilding many packages after an upgrade ...
>

To clarify: python-updater will no longer be needed at some point in
the future when we are no longer using the old python.eclass.

> 2. I have python 2.7 installed and python 3.x is being asked to be
> installed ... isnt that enough? - shorely it can work out what it needs
> from whats been asked for/removed and whats already on the system ...
> instead we need to add these cryptic, poorly explained lines that one
> only finds out from emails etc.  The elog message for the one exception
> asks that the line be added to make.conf without telling the user what
> happens if he upgrades later (as it lists specific versions) or makes
> changes - does that line have any effect, especially if he makes a
> mistake (which I did and I am not sure what it did in the background)?
>

Making things "just work" is complex when trying to juggle 6 or more
supported versions/implementations of python.

We have tried to explain the magic make.conf lines in the Python user guide.

https://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml

We also try to make sure that most users never have to touch
PYTHON_TARGETS, etc; the default values provided by your profile are
set up to allow *stable* python2.7 and python3.2 to work properly.
~arch users are expected to read the docs. ^_^

Re: [gentoo-user] did python-r1 improve user experience?

[gottlieb]

On Sun, Oct 27 2013, Mike Gilbert wrote:

> Making things "just work" is complex when trying to juggle 6 or more
> supported versions/implementations of python.

Indeed.

> We have tried to explain the magic make.conf lines in the Python user guide.
>
> https://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
>
> We also try to make sure that most users never have to touch
> PYTHON_TARGETS, etc; the default values provided by your profile are
> set up to allow *stable* python2.7 and python3.2 to work properly.

> ~arch users are expected to read the docs. ^_^

I am a ~amd64 user and I just read the user-guide. :-)
I do not see any action items for my system; but do see a large number
of reinstalls proposed by emerge

I do not change any python variables in make.conf so emerge --info shows
PYTHON_SINGLE_TARGET="python2_7"
PYTHON_TARGETS="python2_7 python3_2"

a recursive grep -i for python in /etc/portage yields only
./package.use/imaging-pillow:5:virtual/python-imaging -python_targets_python3_2

So I basically have the default except for the imaging/pillow business.

I note that update world wants to rebuild a bunch of packages (the
entire output is below).  Some are qt-related others involve
PYTHON_TARGETS.

Does this mean that I can let the 44 packages / 38 reinstalls update occur
and expect a running system to result?  It is unusual, but I realize not
unprecedented, to have so many reinstalls and I would like to confirm
that this is expected.

thanks,
allan

Re: [gentoo-user] did python-r1 improve user experience?

[gottlieb]

On Thu, Oct 31 2013, gottlieb@nyu.edu wrote:

> On Sun, Oct 27 2013, Mike Gilbert wrote:
>
>> Making things "just work" is complex when trying to juggle 6 or more
>> supported versions/implementations of python.
>
> Indeed.
>
>> We have tried to explain the magic make.conf lines in the Python user guide.
>>
>> https://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
>>
>> We also try to make sure that most users never have to touch
>> PYTHON_TARGETS, etc; the default values provided by your profile are
>> set up to allow *stable* python2.7 and python3.2 to work properly.
>
>> ~arch users are expected to read the docs. ^_^
>
> I am a ~amd64 user and I just read the user-guide. :-)
> I do not see any action items for my system; but do see a large number
> of reinstalls proposed by emerge
>
> I do not change any python variables in make.conf so emerge --info shows
> PYTHON_SINGLE_TARGET="python2_7"
> PYTHON_TARGETS="python2_7 python3_2"
>
> a recursive grep -i for python in /etc/portage yields only
> ./package.use/imaging-pillow:5:virtual/python-imaging -python_targets_python3_2
>
> So I basically have the default except for the imaging/pillow business.
>
> I note that update world wants to rebuild a bunch of packages (the
> entire output is below).  Some are qt-related others involve
> PYTHON_TARGETS.
>
> Does this mean that I can let the 44 packages / 38 reinstalls update occur
> and expect a running system to result?  It is unusual, but I realize not
> unprecedented, to have so many reinstalls and I would like to confirm
> that this is expected.
>
> thanks,
> allan

I realize that I forgot to attach the list of packages emerge wants to
reinstall.  So I did the same emerge command (I always use --ask) and
they are *gone*.  This I don't understand since I didn't sync inbetween
(ls -lt /usr/portage shows nothing since wednesday).

I though all dependencies, etc are resolved locally so why would it
change from 44 packages with 38 reinstalls to 4 packages with no
reinstalls?

Could someone please set me straight?

thanks,
allan

Re: [gentoo-user] did python-r1 improve user experience?

[Alan McKinnon]

On 01/11/2013 15:41, gottlieb@nyu.edu wrote:
> On Thu, Oct 31 2013, gottlieb@nyu.edu wrote:
> 
>> On Sun, Oct 27 2013, Mike Gilbert wrote:
>>
>>> Making things "just work" is complex when trying to juggle 6 or more
>>> supported versions/implementations of python.
>>
>> Indeed.
>>
>>> We have tried to explain the magic make.conf lines in the Python user guide.
>>>
>>> https://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
>>>
>>> We also try to make sure that most users never have to touch
>>> PYTHON_TARGETS, etc; the default values provided by your profile are
>>> set up to allow *stable* python2.7 and python3.2 to work properly.
>>
>>> ~arch users are expected to read the docs. ^_^
>>
>> I am a ~amd64 user and I just read the user-guide. :-)
>> I do not see any action items for my system; but do see a large number
>> of reinstalls proposed by emerge
>>
>> I do not change any python variables in make.conf so emerge --info shows
>> PYTHON_SINGLE_TARGET="python2_7"
>> PYTHON_TARGETS="python2_7 python3_2"
>>
>> a recursive grep -i for python in /etc/portage yields only
>> ./package.use/imaging-pillow:5:virtual/python-imaging -python_targets_python3_2
>>
>> So I basically have the default except for the imaging/pillow business.
>>
>> I note that update world wants to rebuild a bunch of packages (the
>> entire output is below).  Some are qt-related others involve
>> PYTHON_TARGETS.
>>
>> Does this mean that I can let the 44 packages / 38 reinstalls update occur
>> and expect a running system to result?  It is unusual, but I realize not
>> unprecedented, to have so many reinstalls and I would like to confirm
>> that this is expected.
>>
>> thanks,
>> allan
> 
> I realize that I forgot to attach the list of packages emerge wants to
> reinstall.  So I did the same emerge command (I always use --ask) and
> they are *gone*.  This I don't understand since I didn't sync inbetween
> (ls -lt /usr/portage shows nothing since wednesday).
> 
> I though all dependencies, etc are resolved locally so why would it
> change from 44 packages with 38 reinstalls to 4 packages with no
> reinstalls?


Did you make any changes to make.conf between your previous mail and
doing this last test?



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] did python-r1 improve user experience?

[gottlieb]

On Fri, Nov 01 2013, Alan McKinnon wrote:

> On 01/11/2013 15:41, gottlieb@nyu.edu wrote:
>> On Thu, Oct 31 2013, gottlieb@nyu.edu wrote:
>> 
>>> On Sun, Oct 27 2013, Mike Gilbert wrote:
>>>
>>>> Making things "just work" is complex when trying to juggle 6 or more
>>>> supported versions/implementations of python.
>>>
>>> Indeed.
>>>
>>>> We have tried to explain the magic make.conf lines in the Python user guide.
>>>>
>>>> https://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
>>>>
>>>> We also try to make sure that most users never have to touch
>>>> PYTHON_TARGETS, etc; the default values provided by your profile are
>>>> set up to allow *stable* python2.7 and python3.2 to work properly.
>>>
>>>> ~arch users are expected to read the docs. ^_^
>>>
>>> I am a ~amd64 user and I just read the user-guide. :-)
>>> I do not see any action items for my system; but do see a large number
>>> of reinstalls proposed by emerge
>>>
>>> I do not change any python variables in make.conf so emerge --info shows
>>> PYTHON_SINGLE_TARGET="python2_7"
>>> PYTHON_TARGETS="python2_7 python3_2"
>>>
>>> a recursive grep -i for python in /etc/portage yields only
>>> ./package.use/imaging-pillow:5:virtual/python-imaging
>>> -python_targets_python3_2
>>>
>>> So I basically have the default except for the imaging/pillow business.
>>>
>>> I note that update world wants to rebuild a bunch of packages (the
>>> entire output is below).  Some are qt-related others involve
>>> PYTHON_TARGETS.
>>>
>>> Does this mean that I can let the 44 packages / 38 reinstalls update occur
>>> and expect a running system to result?  It is unusual, but I realize not
>>> unprecedented, to have so many reinstalls and I would like to confirm
>>> that this is expected.
>>>
>>> thanks,
>>> allan
>> 
>> I realize that I forgot to attach the list of packages emerge wants to
>> reinstall.  So I did the same emerge command (I always use --ask) and
>> they are *gone*.  This I don't understand since I didn't sync inbetween
>> (ls -lt /usr/portage shows nothing since wednesday).
>> 
>> I though all dependencies, etc are resolved locally so why would it
>> change from 44 packages with 38 reinstalls to 4 packages with no
>> reinstalls?
>
>
> Did you make any changes to make.conf between your previous mail and
> doing this last test?

Good question, but no.

-rw-r--r-- 1 root root 709 Sep 18 14:58 /etc/portage/make.conf

allan

Re: [gentoo-user] did python-r1 improve user experience?

[Alan McKinnon]

On 01/11/2013 17:43, gottlieb@nyu.edu wrote:
> On Fri, Nov 01 2013, Alan McKinnon wrote:
> 
>> On 01/11/2013 15:41, gottlieb@nyu.edu wrote:
>>> On Thu, Oct 31 2013, gottlieb@nyu.edu wrote:
>>>
>>>> On Sun, Oct 27 2013, Mike Gilbert wrote:
>>>>
>>>>> Making things "just work" is complex when trying to juggle 6 or more
>>>>> supported versions/implementations of python.
>>>>
>>>> Indeed.
>>>>
>>>>> We have tried to explain the magic make.conf lines in the Python user guide.
>>>>>
>>>>> https://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
>>>>>
>>>>> We also try to make sure that most users never have to touch
>>>>> PYTHON_TARGETS, etc; the default values provided by your profile are
>>>>> set up to allow *stable* python2.7 and python3.2 to work properly.
>>>>
>>>>> ~arch users are expected to read the docs. ^_^
>>>>
>>>> I am a ~amd64 user and I just read the user-guide. :-)
>>>> I do not see any action items for my system; but do see a large number
>>>> of reinstalls proposed by emerge
>>>>
>>>> I do not change any python variables in make.conf so emerge --info shows
>>>> PYTHON_SINGLE_TARGET="python2_7"
>>>> PYTHON_TARGETS="python2_7 python3_2"
>>>>
>>>> a recursive grep -i for python in /etc/portage yields only
>>>> ./package.use/imaging-pillow:5:virtual/python-imaging
>>>> -python_targets_python3_2
>>>>
>>>> So I basically have the default except for the imaging/pillow business.
>>>>
>>>> I note that update world wants to rebuild a bunch of packages (the
>>>> entire output is below).  Some are qt-related others involve
>>>> PYTHON_TARGETS.
>>>>
>>>> Does this mean that I can let the 44 packages / 38 reinstalls update occur
>>>> and expect a running system to result?  It is unusual, but I realize not
>>>> unprecedented, to have so many reinstalls and I would like to confirm
>>>> that this is expected.
>>>>
>>>> thanks,
>>>> allan
>>>
>>> I realize that I forgot to attach the list of packages emerge wants to
>>> reinstall.  So I did the same emerge command (I always use --ask) and
>>> they are *gone*.  This I don't understand since I didn't sync inbetween
>>> (ls -lt /usr/portage shows nothing since wednesday).
>>>
>>> I though all dependencies, etc are resolved locally so why would it
>>> change from 44 packages with 38 reinstalls to 4 packages with no
>>> reinstalls?
>>
>>
>> Did you make any changes to make.conf between your previous mail and
>> doing this last test?
> 
> Good question, but no.
> 
> -rw-r--r-- 1 root root 709 Sep 18 14:58 /etc/portage/make.conf
> 
> allan
> 

I think we can agree that something must have changed on your system in
the last few days, we just have to find it.

Otherwise we'd have to concede that portage has code like this:

if rnd(0,2)
  do_stupid_emerge()
else
  do_sensible_emerge()
endif

I reckon it's safe to assume portage does not contain code like that :-)

Did you run any portage commands at all that cause changes since
Wednesday? "emerge @preserved-rebuild" and depclean are good candidates,
I often forget about those myself.

How about any file at all in /etc/portage that changes since wednesday?
Or /var/lib/portage/world*?

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] did python-r1 improve user experience?

[gottlieb]

On Fri, Nov 01 2013, Alan McKinnon wrote:

> On 01/11/2013 17:43, gottlieb@nyu.edu wrote:
>> On Fri, Nov 01 2013, Alan McKinnon wrote:
>> 
>>> On 01/11/2013 15:41, gottlieb@nyu.edu wrote:
>>>> On Thu, Oct 31 2013, gottlieb@nyu.edu wrote:
>>>>
>>>>> On Sun, Oct 27 2013, Mike Gilbert wrote:
> I think we can agree that something must have changed on your system in
> the last few days, we just have to find it.
>
> Did you run any portage commands at all that cause changes since
> Wednesday? "emerge @preserved-rebuild" and depclean are good candidates,
> I often forget about those myself.

/var/log/portage/elog shows that the last entry was for tar at 30 nov
just after midnight.  That was the tail end of an update world that
included chromium, which ended just before tar.  So about 9:30pm on
tuesday I started an update world that ended about 3 hours later.
I see no activity after that.  The emerges after that (all --ask) were
aborted when I saw all the reinstalls and then I sent the email to the
group.

>
> How about any file at all in /etc/portage that changes since
> wednesday?

None

newlap gottlieb # ls -l /tmp/ts; find /etc/portage -newer /tmp/ts -ls
-rw-r--r-- 1 root root 0 Oct  1 00:00 /tmp/ts
1190838    4 drwxr-xr-x   2 root     root         4096 Oct  7 10:12 /etc/portage/package.mask
1188156    4 -rw-r--r--   1 root     root         2550 Oct  7 10:13 /etc/portage/package.mask/gnome-3.8
1190759    4 drwxr-xr-x   2 root     root         4096 Oct  8 16:15 /etc/portage/postsync.d
1190586    4 -rw-r--r--   1 root     root           68 Oct  8 16:14 /etc/portage/postsync.d/q-reinitialize
1190761    4 drwxr-xr-x   2 root     root         4096 Oct  8 16:15 /etc/portage/bin
1190467    4 -rwxr-xr-x   1 root     root          190 Oct  8 16:14 /etc/portage/bin/post_sync


> Or /var/lib/portage/world*?
newlap gottlieb # ls -l /var/lib/portage/world*
-rw-r--r-- 1 root portage 1048 Oct 15 19:27 /var/lib/portage/world
-rw-r--r-- 1 root portage 1098 Sep  9 17:21 /var/lib/portage/world~
-rw-r--r-- 1 root portage    0 Oct 15 19:27 /var/lib/portage/world_sets

I do appreciate your efforts and this hunting was instructive for me, but
I can't see you spending any more time on it.  I must have done
something wrong (beyond not including the output of the update world
with 38 reinstalls).

The status now is that update world only wants to update poppler,
util-linux, icu, and python-exec.  I have not re- synced.  I imagine it
is quite safe to do this update (perhaps the python-exec will then
trigger more later).

I will first update a less important machine that also includes
python-exec and if nothing terrible occurs will update the main machine.

I do feel bad for time others have spent on what was clearly some
unknown user error on my part.

thanks again,
allan

Re: [gentoo-user] did python-r1 improve user experience?

[Alan McKinnon]

On 01/11/2013 23:56, gottlieb@nyu.edu wrote:
> I do appreciate your efforts and this hunting was instructive for me, but
> I can't see you spending any more time on it.  I must have done
> something wrong (beyond not including the output of the update world
> with 38 reinstalls).

No problem

> 
> The status now is that update world only wants to update poppler,
> util-linux, icu, and python-exec.  I have not re- synced.  I imagine it
> is quite safe to do this update (perhaps the python-exec will then
> trigger more later).

Uh-oh. Poppler and icu.

Be prepared for all those updates to come rushing back with
preserved-rebuild. Including libreoffice.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] did python-r1 improve user experience?

[Bruce Hill]

On Thu, Oct 31, 2013 at 10:11:59PM -0400, gottlieb@nyu.edu wrote:
> On Sun, Oct 27 2013, Mike Gilbert wrote:
> 
> > Making things "just work" is complex when trying to juggle 6 or more
> > supported versions/implementations of python.
> 
> Indeed.
> 
> > We have tried to explain the magic make.conf lines in the Python user guide.
> >
> > https://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
> >
> > We also try to make sure that most users never have to touch
> > PYTHON_TARGETS, etc; the default values provided by your profile are
> > set up to allow *stable* python2.7 and python3.2 to work properly.
> 
> > ~arch users are expected to read the docs. ^_^
> 
> I am a ~amd64 user and I just read the user-guide. :-)
> I do not see any action items for my system; but do see a large number
> of reinstalls proposed by emerge
> 
> I do not change any python variables in make.conf so emerge --info shows
> PYTHON_SINGLE_TARGET="python2_7"
> PYTHON_TARGETS="python2_7 python3_2"
> 
> a recursive grep -i for python in /etc/portage yields only
> ./package.use/imaging-pillow:5:virtual/python-imaging -python_targets_python3_2
> 
> So I basically have the default except for the imaging/pillow business.
> 
> I note that update world wants to rebuild a bunch of packages (the
> entire output is below).  Some are qt-related others involve
> PYTHON_TARGETS.
> 
> Does this mean that I can let the 44 packages / 38 reinstalls update occur
> and expect a running system to result?  It is unusual, but I realize not
> unprecedented, to have so many reinstalls and I would like to confirm
> that this is expected.

I don't remember seeing your emerge output; but if this has to do with
pyton-exec you're not in the boat alone ... it is terribly fubared atm.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] did python-r1 improve user experience?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/27/2013 02:30 AM, Mike Gilbert wrote:
> 
> The (non-)relationship between eselect python and PYTHON_TARGETS
> is something that would be nice to resolve, but I don't know how to
> do it. PYTHON_SINGLE_TARGET will probably cause problems if/when
> packages start supporting python3 only.
> 

I think python-single-r1 is one of the major problems for users,
because they have to mess with two variables/useflags. Most just put
PYTHON_SINGLE_TARGET="python3_3" or something in make.conf which then
again affects all packages and WILL cause blockers/unresolvable deps.

Afair in the very early versions we just picked the "best"
implementation and were done with it (since a python-single-r1 package
should not provide modules anyway).

What is wrong with that approach (except that it still causes useless
rebuilds)? Do users really need that sort of control over non-module
packages? If they really do, you can still do some additional work and
make a real python-r1 package out of it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSbQEKAAoJEFpvPKfnPDWz5vsIAIjvgXeR3bVy5ayT8XpZDjZ1
G9hghpRqVr6C4ITTXeFnOQcmOqtcHb2zt6rudgjV8//4H9Vr+ZSqUmPAMaaM7aN6
A0ujl6+awMDoK3GUHZ05Hk0W+gy561OkeFpoCMkBZ1Xe31DEo3nnWUktYOfscal6
QAWQRUbONX/efoDh0C6WOSMfpgvgMn2TYvem+SOQ7PTiK01rY9Hoy5+JiN1g/e/W
4dmvmxXMQ8e7n0Ec/L0vtmey4NM6znqMQHzvK6r5Aed/6B1hzwNRvFz0R7QcjjUO
B/kYopuTOzj8jr52Vl00rFVRP69bMFq1M4lldQiy6dIznOGr8WLX23UhSHS1J30=
=nAwp
-----END PGP SIGNATURE-----

Re: [gentoo-user] did python-r1 improve user experience?

[Mike Gilbert]

On Sun, Oct 27, 2013 at 8:03 AM, hasufell <hasufell@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/2013 02:30 AM, Mike Gilbert wrote:
>>
>> The (non-)relationship between eselect python and PYTHON_TARGETS
>> is something that would be nice to resolve, but I don't know how to
>> do it. PYTHON_SINGLE_TARGET will probably cause problems if/when
>> packages start supporting python3 only.
>>
>
> I think python-single-r1 is one of the major problems for users,
> because they have to mess with two variables/useflags. Most just put
> PYTHON_SINGLE_TARGET="python3_3" or something in make.conf which then
> again affects all packages and WILL cause blockers/unresolvable deps.
>
> Afair in the very early versions we just picked the "best"
> implementation and were done with it (since a python-single-r1 package
> should not provide modules anyway).
>
> What is wrong with that approach (except that it still causes useless
> rebuilds)? Do users really need that sort of control over non-module
> packages? If they really do, you can still do some additional work and
> make a real python-r1 package out of it.

I guess the obvious downside to doing that would be extraneous
dependencies. You would end up with packages that are installed for
only one version of python, but "depend" on libraries for every
version of python in PYTHON_TARGETS. That's probably not a big deal.

However, you could potentially have a *library* that supports only a
single version of python and uses python-single-r1; in that case we
absolutely must know for which version of python it was installed to
allow other python-single-r1 packages to depend on it correctly.