1 |
On Sat, 26 May 2012 22:45:18 +0400 |
2 |
Maxim Koltsov <maksbotan@g.o> wrote: |
3 |
|
4 |
> 2012/5/26 Krzysztof Pawlik <nelchael@g.o>: |
5 |
> > On 26/05/12 15:09, Nikolaj Sjujskij wrote: |
6 |
> >> Den 2012-05-26 17:07:29 skrev Michał Górny <mgorny@g.o>: |
7 |
> >> |
8 |
> >>> On Sat, 26 May 2012 17:01:26 +0400 |
9 |
> >>> "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
10 |
> >>> |
11 |
> >>>> > So I think the second part of this (x.y to x.y+1 transitions, |
12 |
> >>>> > in the Python world, are generally relatively smooth) |
13 |
> >>>> > invalidates your point in the first part: if the transitions |
14 |
> >>>> > are generally smooth, then yes, when Python 3.3 gets |
15 |
> >>>> > stabilized, I want all of my Python packages to be available |
16 |
> >>>> > from the 3.3 interpreter. |
17 |
> >>>> Let's take a "stable" user who updates (`emerge --update --deep |
18 |
> >>>> --newuse @world`) his/her system regularly. |
19 |
> >>>> Python 3.3 is released, added to Portage tree and eventually |
20 |
> >>>> unmasked. PYTHON_TARGETS variable is changed to include 3.3. And |
21 |
> >>>> suddenly `emerge --newuse @world` on stable system suggests |
22 |
> >>>> rebuilding of every package using new eclass, because new |
23 |
> >>>> (though disabled) USE-flags was added. And when Python 3.3 is |
24 |
> >>>> keyworded stable, hence bringing new default PYTHON_TARGETS, |
25 |
> >>>> user should now rebuild those packages once more, but now, at |
26 |
> >>>> least, not uselessly. |
27 |
> >>>> |
28 |
> >>>> Just yesterday I had www-servers/uwsgi recompiled because of |
29 |
> >>>> changed RUBY_TARGETS. And I even have no Ruby installed. |
30 |
> >>> |
31 |
> >>> I suggest you report a bug against portage and/or PMS. |
32 |
> >> Excuse me, but I really fail to see how this could be their fault. |
33 |
> > |
34 |
> > Yes, you do. Let me explain: there was a thread some time ago about |
35 |
> > portage rebuilding package when new USE flag is introduced in |
36 |
> > ebuild that does not change enabled USE set, that's how it's |
37 |
> > related. |
38 |
> |
39 |
> This was my first thought too: if just appeared flag is not set, there |
40 |
> is no sense to rebuild. But there is one possible case when this |
41 |
> assumption is false. Image that foo has support for bar and this |
42 |
> support was on by default and had no useflag. Suddenly package |
43 |
> maintainer decides, no matter why, make it optional and off by |
44 |
> default. He adds useflag to IUSE and it's not set by default. Then not |
45 |
> rebuilding it is *wrong* behavior. |
46 |
> Yes i know that this example is rather abstract and very unlikely to |
47 |
> happen, but we must consider all cases. |
48 |
|
49 |
Then author may revbump the package to make users happier. |
50 |
|
51 |
-- |
52 |
Best regards, |
53 |
Michał Górny |