From: "Nikolaj Sjujskij" <sterkrig@myopera.com>
To: gentoo-python <gentoo-python@lists.gentoo.org>
Cc: "Dirkjan Ochtman" <djc@gentoo.org>
Subject: Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass
Date: Sat, 26 May 2012 17:01:26 +0400 [thread overview]
Message-ID: <op.wew2gozzh7emz2@gentoobook.trollsnaetverk> (raw)
In-Reply-To: <CAKmKYaCo3_3PuaW_dckR1-rExAa86ZkoPGUSMZOJGJkU1TnnCw@mail.gmail.com>
> So I think the second part of this (x.y to x.y+1 transitions, in the
> Python world, are generally relatively smooth) invalidates your point
> in the first part: if the transitions are generally smooth, then yes,
> when Python 3.3 gets stabilized, I want all of my Python packages to
> be available from the 3.3 interpreter.
Let's take a "stable" user who updates (`emerge --update --deep --newuse
@world`) his/her system regularly.
Python 3.3 is released, added to Portage tree and eventually unmasked.
PYTHON_TARGETS variable is changed to include 3.3. And suddenly `emerge
--newuse @world` on stable system suggests rebuilding of every package
using new eclass, because new (though disabled) USE-flags was added. And
when Python 3.3 is keyworded stable, hence bringing new default
PYTHON_TARGETS, user should now rebuild those packages once more, but now,
at least, not uselessly.
Just yesterday I had www-servers/uwsgi recompiled because of changed
RUBY_TARGETS. And I even have no Ruby installed.
> So, I'd prefer it if, instead of speaking up about general concerns
> that the new eclass isn't ready or has serious problems, people please
> file one bug each about each serious problem they have run into,
> found, or are concerned about, CC the python team, and we'll try to
> take a look.
I had written about problems with new eclass a couple of weeks ago here.
Not that anybody cares that now any user not caring about dev-lang/python
explicitly would get Python 2.7 and all his modules compiled twice for no
good reason (except "we can't think out more sensible default for new
eclass"). Whether or not does he *really* need Python 2.x or stable and
included-in-stage3 Python 3.2 suffices for him.
next prev parent reply other threads:[~2012-05-26 13:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAB_KkxwspDjWOpV7FSdwxD5MHS-qjtxrUQBiwbsc2yRhqXQntQ@mail.gmail.com>
2012-05-26 9:32 ` [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass Maxim Koltsov
2012-05-26 9:53 ` Dirkjan Ochtman
2012-05-26 13:01 ` Nikolaj Sjujskij [this message]
2012-05-26 13:07 ` Michał Górny
2012-05-26 13:09 ` Nikolaj Sjujskij
2012-05-26 18:28 ` Krzysztof Pawlik
2012-05-26 18:45 ` Maxim Koltsov
2012-05-26 19:07 ` Michał Górny
2012-06-01 10:36 ` Nikolaj Sjujskij
2012-05-26 13:33 ` Mike Gilbert
2012-06-01 12:42 ` Nikolaj Sjujskij
2012-05-26 9:53 ` Michał Górny
2012-05-26 9:55 ` Dirkjan Ochtman
2012-05-26 10:06 ` Michał Górny
2012-05-26 18:31 ` Krzysztof Pawlik
2012-05-26 23:18 ` Mike Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.wew2gozzh7emz2@gentoobook.trollsnaetverk \
--to=sterkrig@myopera.com \
--cc=djc@gentoo.org \
--cc=gentoo-python@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox