| 1 |
Ühel kenal päeval, E, 10.04.2017 kell 16:17, kirjutas William L. |
| 2 |
Thomson Jr.: |
| 3 |
> On Mon, 10 Apr 2017 16:01:55 -0400 |
| 4 |
> "William L. Thomson Jr." <wlt-ml@××××××.com> wrote: |
| 5 |
> > |
| 6 |
> > Ok I concede on removing older versions. Lets put old version |
| 7 |
> > aside. |
| 8 |
> > |
| 9 |
> > What about adding new? You still have to add the new version to |
| 10 |
> > PYTHON_COMPAT in each ebuild right? |
| 11 |
> > |
| 12 |
> > What about users? Do they need do anything if they have specific |
| 13 |
> > targets set? Or all should just use Wildcard and if in ~arch have |
| 14 |
> > 3-4+ pythons. |
| 15 |
> > |
| 16 |
> > Even if house cleaning, removing old is not an issue. You still |
| 17 |
> > have |
| 18 |
> > adding new, and the end user experience. |
| 19 |
> |
| 20 |
> What about dependencies? Their slots must be increased as well right? |
| 21 |
> |
| 22 |
> In fact that effects removal. You cannot remove an old version if any |
| 23 |
> depend on that slot specifically. |
| 24 |
|
| 25 |
The USE dep requirement on the old python target will go away with the |
| 26 |
removal of it in eclass and I don't know what slots have to do with it. |
| 27 |
This circles back to first gathering the basic knowledge of how these |
| 28 |
things work right now and why, even if I don't necessarily agree with |
| 29 |
the way this was pointed out. |
| 30 |
|
| 31 |
> Rather in Java's case. If an older is removed, the ebuild does not |
| 32 |
> need |
| 33 |
> to be modified ever.... Nor if a new one is added unless it breaks. |
| 34 |
|
| 35 |
Nor does in python, it's just a janitorial process to reduce the |
| 36 |
ebuilds by 2 bytes or something. One which can be scripted and rather |
| 37 |
easily pushed thanks to not CVS anymore. |
Archives