FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-27-2010, 02:33 PM
Thomas Sachau
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

Hi together,

since i am not able to get any real argument or even discussion on IRC nor on this mailing list from
Arfrever (main person behind those changes), i would like to raise the following points now on this
mailing list as told on IRC, so he gets the chance to answer those points and to clear the issues:

-major changes to python eclasses have been done without peer review on this mailing list. This
includes pulling in python-3* versions, even when they are not required nor used on the user system

Our policy is, that major changes to main eclasses should previously shown and discussed publically
on this mailing list, this did not happen for the python eclass. I think, he was already told about
it, but i still did not see any RFC about those eclass changes.
Additionally, those changes now pull in python-3 for every user, also no package does require
python-3 nor will it be used, since the main python version still has to be python-2. This results
in vasted time for additional compilation (both for python-3 and every python module, which is able
to work with python-3) and vasted space on the user system, since those files are not used anywhere.
Additionally, every additional package raises the security risks since it raises the amount of code
around, also this is nothing python specific.
Since python-3 is totally optional, it should be an option to pull it in, not a forced pull, where
users have to know, that is is optional and could be masked.

-A news item, which is only shown, once python-3* is installed.

It is only shown _after_ installation of python-3.
It just suggests to not set python-3 as main python version and to run the python-updater, but it
does not tell the user, that python-3 is still completly optional and not needed for him.

-Arfrever also said, he would add a seperate news item, when python-3 gets stabilized.

Now the stabilisation bug is open, the first arch is stabilized and i still dont see any news item,
which does prepare the users in advance.


Beside those points, one additional main issue is, that i and others dont seem to be able to have a
discussion with Arfrever about this topics. He says, he has no time for it or says, that he already
had shown arguments, but cannot show any evidence or just stops responding without any note.

Even if all those changes would have good reasons for them, the way, how they are done and
communicated is not very well chosen. And since i dont seem to be able to get any discussion with
Arfrever about those points, i will also CC devrel. For now, to inform them and, also in the hope,
that it is not needed and those issues can be resolved, in preparation for a discussion and decision
on those topics, if needed later one.


So for Arfrever: I also CCed you, so that i can be sure, that you get the mail. Please answer to all
of my above points with arguments. Choose whatever way you prefer for that (public mail, private
mail, public IRC discussion or private message via IRC). If you missed some points or others appear,
i will answer and ask about those.
If you do not answer at all or do not answer with arguments to my satisfaction within 14 days, i
will escalate those issues to devrel.

--
Thomas Sachau

Gentoo Linux Developer
 
Old 05-27-2010, 03:30 PM
Gilles Dartiguelongue
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

Le jeudi 27 mai 2010 16:33 +0200, Thomas Sachau a crit :
> Hi together,
>
> since i am not able to get any real argument or even discussion on IRC nor on this mailing list from
> Arfrever (main person behind those changes), i would like to raise the following points now on this
> mailing list as told on IRC, so he gets the chance to answer those points and to clear the issues:
>
> -major changes to python eclasses have been done without peer review on this mailing list. This
> includes pulling in python-3* versions, even when they are not required nor used on the user system

python3 being pulled has already been discussed on this mailing list.
Any ebuild that has a >=python-2 dependency will pull python3 (at least
with portage).

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo
 
Old 06-05-2010, 02:43 PM
Arfrever Frehtes Taifersar Arahesis
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

2010-05-27 16:33:39 Thomas Sachau napisał(a):
> Hi together,
>
> since i am not able to get any real argument or even discussion on IRC nor on this mailing list from
> Arfrever (main person behind those changes), i would like to raise the following points now on this
> mailing list as told on IRC, so he gets the chance to answer those points and to clear the issues:
>
> -major changes to python eclasses have been done without peer review on this mailing list.

There weren't any major changes in python.eclass in last months. In r1.96:r1.100 I committed a set of minor changes.
Some code was moved, which might cause false impression that there were some major changes:
- "MISCELLANEOUS FUNCTIONS" section (with 8 functions) was moved to before "FUNCTIONS FOR PACKAGES SUPPORTING
INSTALLATION FOR MULTIPLE PYTHON ABIS" section.
- python_pkg_setup() function was moved to "MISCELLANEOUS FUNCTIONS" section.
- A part of python_mod_cleanup() function was split to _python_clean_compiled_modules() function.
python_mod_cleanup() now calls _python_clean_compiled_modules().
- 2 loops in python_mod_optimize() were divided and some code was reindented.

> This includes pulling in python-3* versions

It's untruth. python.eclass or distutils.eclass don't enforce any particular version of Python.

> -A news item, which is only shown, once python-3* is installed.
>
> It is only shown _after_ installation of python-3.

You might file an enhancement request for Portage to show news items before installation.

> -Arfrever also said, he would add a seperate news item, when python-3 gets stabilized.

I never said it. The plan was to have 1 news item for all users, who have installed Python 3.1.

> Beside those points, one additional main issue is, that i and others dont seem to be able to have a
> discussion with Arfrever about this topics.

I'm answering to new (unanswered), rational arguments about these topics.

> He says, he has no time for it or says, that he already had shown arguments, but cannot show
> any evidence or just stops responding without any note.

There had been multiple threads about Python 3. Read e-mails written by me or Dirkjan Ochtman in the following threads:
http://archives.gentoo.org/gentoo-dev/msg_115ce6fa1a09de286bf58db12df463c6.xml
http://archives.gentoo.org/gentoo-dev/msg_814e67764c17f88bde94f22e9a392e4f.xml
http://archives.gentoo.org/gentoo-dev/msg_2591c1b9a7e7b72383d3841bc05dc417.xml

--
Arfrever Frehtes Taifersar Arahesis
 
Old 06-05-2010, 03:49 PM
Thomas Sachau
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

Am 05.06.2010 16:43, schrieb Arfrever Frehtes Taifersar Arahesis:
> 2010-05-27 16:33:39 Thomas Sachau napisał(a):
>> Hi together,
>>
>> since i am not able to get any real argument or even discussion on IRC nor on this mailing list from
>> Arfrever (main person behind those changes), i would like to raise the following points now on this
>> mailing list as told on IRC, so he gets the chance to answer those points and to clear the issues:
>>
>> -major changes to python eclasses have been done without peer review on this mailing list.
>
> There weren't any major changes in python.eclass in last months. In r1.96:r1.100 I committed a set of minor changes.
> Some code was moved, which might cause false impression that there were some major changes:
> - "MISCELLANEOUS FUNCTIONS" section (with 8 functions) was moved to before "FUNCTIONS FOR PACKAGES SUPPORTING
> INSTALLATION FOR MULTIPLE PYTHON ABIS" section.
> - python_pkg_setup() function was moved to "MISCELLANEOUS FUNCTIONS" section.
> - A part of python_mod_cleanup() function was split to _python_clean_compiled_modules() function.
> python_mod_cleanup() now calls _python_clean_compiled_modules().
> - 2 loops in python_mod_optimize() were divided and some code was reindented.

You dont call the support for multiple python slots a "major change"? I did not see any RFC about
your idea, concept or implementation.

Even when other people, after the implementation was done, tried to talk with you about your way and
pointing out other possible ways, which would be less complex (e.g. the "ruby way" or implementation
on package manager side), you did not listen or refused to accept them because some optional
additional feature might not work with that way.

>
>> This includes pulling in python-3* versions
>
> It's untruth. python.eclass or distutils.eclass don't enforce any particular version of Python.

If any package does inherit python or distutils eclass, then those eclasses do pull in
"dev-lang/python", which is unversioned, so it will always pull in the latest version, in this case
python-3*. You could change this, so it allows any major installed slot to satisfy the python
dependency.

Additionally, your implementation pulls in python-3* for packages, which support multiple versions
of python, but would work fine with the already installed python-2* version. This behaviour might be
fine, when one could actually use python-3* as main version, but currently you pull in an unneeded
and unused python slot.

And your current implementation requires the use of another tool, python-updater, to maintain python
related ebuilds, since your current implementation does not allow the package manager to see the
needed/used dependencies and to (re)compile the packages as needed.

>
>> -A news item, which is only shown, once python-3* is installed.
>>
>> It is only shown _after_ installation of python-3.
>
> You might file an enhancement request for Portage to show news items before installation.

Huh? Your news item explicitly requires the installation of python-3, before it is shown. This has
nothing to do with the package manager, it is, what you define in your news item.

>
>> Beside those points, one additional main issue is, that i and others dont seem to be able to have a
>> discussion with Arfrever about this topics.
>
> I'm answering to new (unanswered), rational arguments about these topics.
>
>> He says, he has no time for it or says, that he already had shown arguments, but cannot show
>> any evidence or just stops responding without any note.
>
> There had been multiple threads about Python 3. Read e-mails written by me or Dirkjan Ochtman in the following threads:
> http://archives.gentoo.org/gentoo-dev/msg_115ce6fa1a09de286bf58db12df463c6.xml
> http://archives.gentoo.org/gentoo-dev/msg_814e67764c17f88bde94f22e9a392e4f.xml
> http://archives.gentoo.org/gentoo-dev/msg_2591c1b9a7e7b72383d3841bc05dc417.xml

I did read the threads about python-3, but i still dont see any real argument, why you want everyone
to install python-3*, also it is not required, not needed and not used. Also, you have written, that
the python team does not suggest to mask python-3, but did not give any reason for that. So could
you do that now?


--
Thomas Sachau

Gentoo Linux Developer
 
Old 06-05-2010, 06:31 PM
Harald van Dijk
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
> If any package does inherit python or distutils eclass, then those eclasses do pull in
> "dev-lang/python", which is unversioned, so it will always pull in the latest version, in this case
> python-3*. You could change this, so it allows any major installed slot to satisfy the python
> dependency.

A dependency on dev-lang/python *is* satisfied by any slot, any version. You've
been told so already, if I recall correctly.
 
Old 06-05-2010, 08:06 PM
Sebastian Pipping
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

Thomas, Arfrever,


the way this discussion currently works does not look fruitful to me.
Questions I would like to raise:

- How come you don't agree on facts?

- Is this about processes or results?

- Have you tried to understand the other side's problem?

- Could you try a question-explanation of conversation style, instead?

Best,



Sebastian
 
Old 06-05-2010, 11:04 PM
Thomas Sachau
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

Am 05.06.2010 20:31, schrieb Harald van Dijk:
> On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
>> If any package does inherit python or distutils eclass, then those eclasses do pull in
>> "dev-lang/python", which is unversioned, so it will always pull in the latest version, in this case
>> python-3*. You could change this, so it allows any major installed slot to satisfy the python
>> dependency.
>
> A dependency on dev-lang/python *is* satisfied by any slot, any version. You've
> been told so already, if I recall correctly.
>
>

Every slot and every version *should* satisfy a "dev-lang/python" dependency, but currently such
unspecified version dependency does automaticly pull in the latest version/slot, which in case of
python does mean python-3*, even when you have e.g. python:2.6 installed.

--
Thomas Sachau

Gentoo Linux Developer
 
Old 06-05-2010, 11:38 PM
Harald van Dijk
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

On Sun, Jun 06, 2010 at 01:03:48AM +0200, Thomas Sachau wrote:
> Am 05.06.2010 20:31, schrieb Harald van Dijk:
> > On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
> >> If any package does inherit python or distutils eclass, then those eclasses do pull in
> >> "dev-lang/python", which is unversioned, so it will always pull in the latest version, in this case
> >> python-3*. You could change this, so it allows any major installed slot to satisfy the python
> >> dependency.
> >
> > A dependency on dev-lang/python *is* satisfied by any slot, any version. You've
> > been told so already, if I recall correctly.
>
> Every slot and every version *should* satisfy a "dev-lang/python" dependency, but currently such
> unspecified version dependency does automaticly pull in the latest version/slot, which in case of
> python does mean python-3*, even when you have e.g. python:2.6 installed.

Fine, I'll be as explicit as possible: not quite. I have a Python 3-free system. I created
a dummy ebuild that does nothing but pull in unversioned python. Let's
see how it behaves.

$ emerge -pv python

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild NS ] dev-lang/python-3.1.2-r3 [2.6.5-r2] USE="gdbm ipv6 ncurses readline sqlite ssl threads tk (wide-unicode) xml -build -doc -examples -wininst" ELIBC="(-uclibc)" 9,558 kB

$ cat test-2.0.ebuild
KEYWORDS="~amd64"
SLOT="0"
DEPEND="dev-lang/python"

$ emerge -pv test

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] test/test-2.0 0 kB [1]

Total: 1 package (1 new), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /etc/portage/overlay

Note how python 3 is *not* pulled in, despite an unversioned dependency on dev-lang/python.
You only get that if you tell portage to try and update dependencies as
well, and yes, if you do that, it's only fair that it attempts to update python.
 
Old 06-06-2010, 12:08 AM
Sebastian Pipping
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

Thomas,


On 06/06/10 01:04, Thomas Sachau wrote:
> Every slot and every version *should* satisfy a "dev-lang/python" dependency, but currently such
> unspecified version dependency does automaticly pull in the latest version/slot, which in case of
> python does mean python-3*, even when you have e.g. python:2.6 installed.

can you explain how that happens?



Sebastian
 
Old 06-06-2010, 02:01 AM
Thomas Sachau
 
Default Actions of python team, especially Arfrever wrt python eclass and python-3*

Am 06.06.2010 01:38, schrieb Harald van Dijk:
> On Sun, Jun 06, 2010 at 01:03:48AM +0200, Thomas Sachau wrote:
>> Am 05.06.2010 20:31, schrieb Harald van Dijk:
>>> On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
>>>> If any package does inherit python or distutils eclass, then those eclasses do pull in
>>>> "dev-lang/python", which is unversioned, so it will always pull in the latest version, in this case
>>>> python-3*. You could change this, so it allows any major installed slot to satisfy the python
>>>> dependency.
>>>
>>> A dependency on dev-lang/python *is* satisfied by any slot, any version. You've
>>> been told so already, if I recall correctly.
>>
>> Every slot and every version *should* satisfy a "dev-lang/python" dependency, but currently such
>> unspecified version dependency does automaticly pull in the latest version/slot, which in case of
>> python does mean python-3*, even when you have e.g. python:2.6 installed.
>
> Fine, I'll be as explicit as possible: not quite. I have a Python 3-free system. I created
> a dummy ebuild that does nothing but pull in unversioned python. Let's
> see how it behaves.
>
> $ emerge -pv python
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild NS ] dev-lang/python-3.1.2-r3 [2.6.5-r2] USE="gdbm ipv6 ncurses readline sqlite ssl threads tk (wide-unicode) xml -build -doc -examples -wininst" ELIBC="(-uclibc)" 9,558 kB
>
> $ cat test-2.0.ebuild
> KEYWORDS="~amd64"
> SLOT="0"
> DEPEND="dev-lang/python"
>
> $ emerge -pv test
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild N ] test/test-2.0 0 kB [1]
>
> Total: 1 package (1 new), Size of downloads: 0 kB
> Portage tree and overlays:
> [0] /usr/portage
> [1] /etc/portage/overlay
>
> Note how python 3 is *not* pulled in, despite an unversioned dependency on dev-lang/python.
> You only get that if you tell portage to try and update dependencies as
> well, and yes, if you do that, it's only fair that it attempts to update python.
>
>

And you do want to update world with all the dependencies of it, so even if it is not pulled in
during installation, it will be pulled in during world update.

Since python-3* is currently useless and not required for any package, the dependency should by
default only pull in python-2* like this:

=dev-lang/python-2*

With that, the default way would not pull in a package, which is not needed or used. And if there
will be any package, which really requires python-3*, it simply requests it in (R)DEPEND of the
ebuild, which then would overwrite the default value of the eclass and pull in python-3*.

Are there any reasons to pull in a package, which is not requested by the user, not required by any
package and by default not used by any package?



--
Thomas Sachau

Gentoo Linux Developer
 

Thread Tools




All times are GMT. The time now is 12:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org