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: Maxim Koltsov <maksbotan@g.o>
From: Michał Górny <mgorny@g.o>
Subject: Re: python-distutils.eclass vs. python.eclass + distutils.eclass
Date: Sat, 26 May 2012 21:07:38 +0200
On Sat, 26 May 2012 22:45:18 +0400
Maxim Koltsov <maksbotan@g.o> wrote:

> 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.

Then author may revbump the package to make users happier.

-- 
Best regards,
Michał Górny
Attachment:
signature.asc (PGP signature)
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
Re: python-distutils.eclass vs. python.eclass + distutils.eclass
-- Maxim Koltsov
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.