Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-python
Navigation:
Lists: gentoo-python: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Krzysztof Pawlik <nelchael@g.o>
From: Maxim Koltsov <maksbotan@g.o>
Subject: Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Date: Sat, 26 May 2012 22:45:18 +0400
2012/5/26 Krzysztof Pawlik <nelchael@g.o>:
> On 26/05/12 15:09, Nikolaj Sjujskij wrote:
>> Den 2012-05-26 17:07:29 skrev Michał Górny <mgorny@g.o>:
>>
>>> On Sat, 26 May 2012 17:01:26 +0400
>>> "Nikolaj Sjujskij" <sterkrig@...> wrote:
>>>
>>>> > 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.
>>>
>>> I suggest you report a bug against portage and/or PMS.
>>  Excuse me, but I really fail to see how this could be their fault.
>
> Yes, you do. Let me explain: there was a thread some time ago about portage
> rebuilding package when new USE flag is introduced in ebuild that does not
> change enabled USE set, that's how it's related.

This was my first thought too: if just appeared flag is not set, there
is no sense to rebuild. But there is one possible case when this
assumption is false. Image that foo has support for bar and this
support was on by default and had no useflag. Suddenly package
maintainer decides, no matter why, make it optional and off by
default. He adds useflag to IUSE and it's not set by default. Then not
rebuilding it is *wrong* behavior.
Yes i know that this example is rather abstract and very unlikely to
happen, but we must consider all cases.

> --
> Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
> desktop-misc, java, vim, kernel, python, apache...
>


Replies:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Michał Górny
References:
python-distutils.eclass vs. python.eclass + distutils.eclass
-- Maxim Koltsov
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Dirkjan Ochtman
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Nikolaj Sjujskij
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Michał Górny
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Nikolaj Sjujskij
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Krzysztof Pawlik
Navigation:
Lists: gentoo-python: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Next by thread:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Previous by date:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Next by date:
Re: python-distutils.eclass vs. python.eclass + distutils.eclass


Updated Jun 29, 2012

Summary: Archive of the gentoo-python mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.