Опять в интернете обидели (загадка внутри)

В чём именно выражается твоя проблема?

ЗЫ:

$ grep python3_6 /usr/portage/profiles/features/prefix/standalone/kernel-2.6.16+/use.mask
python_single_target_python3_6
python_targets_python3_6

В чём именно выражается твоя проблема?

В том, что нужно сносить 3.5 и ставить 3.6 на этапе установки, пересобирая трешак на 3.6, на что уходит время.

Система полностью собирается на 3.6 включая гуйки.

Но я, кажется, понял в чем дело, просто у некоторых стабильных пакетов нет юза 3.6, собраться они могут только на 3.5, потому несмотря на давно стабильный 3.6 — мы имеем то, что имеем.

собраться они могут только на 3.5

Сильное заявление. Есть примеры?

я предположил, не заявлял, другого объяснения не вижу.

Но примеры есть (которые приходилось садить на 2.7):

до гуя:

• dev-python/typing
• dev-python/certifi
• dev-python/setuptools
• dev-python/six
• dev-python/pyxattr ?

гуя:

• media-gfx/fontforge
• media-video/mpv

в декабре прошлого года их было больше, это на данный момент, как минимум.

Первые питоньи кишки — в поставке стейджа, так что не вывернёшься.

был бы питон 3.6, хотелось бы 3.5 или 3.8

Меня не так интересует python 3.6 или 3.5, лучше бы python 2 дропнули. Или еще лучше переписали бы Portage на C++, а то его быстродействие уже не выдерживает никакой критики.

Можно руками в локальном оверлее дописать 3.6 и с очень большой вероятностью ничего не сломается. Почему мейнтейнеры этого не сделали прямо в дереве — не знаю, но предполагаю дефицит свободных рук.

Маинтейнер забухал

лучше бы python 2 дропнули

git, nodejs, например, не взлетят.

Система полностью собирается на 3.6 включая гуйки.

Я же тебе вроде ясно показал, что флаги python_single_target_python3_6 и python_targets_python3_6 замаскированы.

Portage на C++

Сам поищешь сколько тут таких желающих было (чуть ли не начинали писать, у некоторых, наверняка, даже до строчки «#include» дошло)? И где они теперь?

система сборки scons-2.x тоже работаeт только с python2.7

Или еще лучше переписали бы Portage на C++

Палудис на плюсах так же медленно просчитывает. Не думаю, что плюсовый портеж что-то изменит.

Сам поищешь сколько тут таких желающих было

Думаешь, типичный лоровец смог бы в одиночку на плюсах написать, если даже сами разрабы портежа не трепыхаются об этом?

Ок, я сразу не понял, думал ты что-то личное показал, а не профиль.

Значит тесты не пройдены на сборке stage-а с 3.6 - вот и не собирают.

Поинтересоваться напрямую у Gentoo Python team или у Releng team - не судьба?

Это для Gentoo Prefix - там весь третий питон замаскирован. К обычной системе это не имеет отношения:

pinkbyte@oas1 ~ $ emerge -1Opv setuptools

These are the packages that would be merged, in order:

[ebuild   R    ] dev-python/setuptools-36.7.2::gentoo  USE="{-test}" PYTHON_TARGETS="python2_7 python3_5 (-pypy) (-pypy3) -python3_4 -python3_6" 710 KiB

Total: 1 package (1 reinstall), Size of downloads: 710 KiB

Обрати внимание что флаг размаскирован. У меня stable, руками в /etc/portage/profile тоже не размаскировал.

не судьба?

да weechat чего-то не собирается)

Paladius же на c++ написан, но что-то ему это не помогло.

Обычно типичный лоровец строит грандиозные планы переписать на <любой язык>, призывая даже других в помощь, не попытавшись даже разобраться какой именно блок portage работает медленно (как это энтузиастам и предлагают сделать) и разобраться в алгоритме того, как это работает сейчас. То есть дальше «да я сейчас...» покажи у кого не ушло.

Понял.

Врядли портаж перепишут в ближайшее время, в нем довольно много всякой функциональности, особенно в FEATURES. Неужели опять будут писать студенты на Google Code Summer... Естественно меня это уже не волнует (под SSD все более-менее терпимо) — я не программист (хотя пишу хеллоу ворлды на питоне) и в одиночку этим заниматься безумие.

Портаж каждый раз просчитывает зависимости пакетов с нуля из кучи мелких файлов, насколько я понял, и сам этот просчет не оптимизирован.