Стабильный выпуск Portage 3.0

Теперь поддерживается только версия 3.2 и младше.

хм.

Значительно ускорены вычисления

Хм… «На глаз» совершенно не заметно. А без сравнения до и после вообще 4.2.

а что из того что младше питона 3.6 еще дышит?

Pypy 3.6

https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/portage?id=bb3180edb5d310d5382bb3c0772c06be0b354806

А на сайте генту новость о СТАБИЛИЗАЦИИ ВЕТКИ 3.0

Версия 3.0 выпилена еще в августе.

Так что заголовок новости явно не корректный, стабильный релиз 3.0.4, 3.0 вышел в июле.

Да, нормуль. На неторопливом железе уже интереснее.

Обычная путаница между «младше» в значении «меньшей версии» и «младше» в буквальном смысле, т. е. «появившееся позже».

Сообщается о приблизительно 50-60% выигрыша при компиляции «мира».

Не надо вводить людей в заблуждение. 50-60% выигрыша при просчете

emerge -uDvpU --with-bdeps=y @world 

а не при компиляции

У меня на системе – стабильная 3.0.4-r1, since 2020-08-31. Так что новость – боян.

50-60% выигрыша при просчете

Как тормозило, так и тормозит.

Как станет многопоточным, так перестанет наверное.

Это означает что на версиях выше 3.2 не работает.

Я читал на другом сайте что были попытки переписать на с++ или rust и запутались в коде. Так вот, если нужно парсить выхлопы и конфиги + многопоточность и скорость то им всего лишь нужно было переписать его на Go.

50-60% выигрыша при компиляции «мира».

А что, было-бы совсем не плохо.

Да, ускорили только ресолвинг зависимостей в portage, а больше и не могут. Больше это в ведении gcc и флагов оптимизации.

Надо мне будет протестировать какой ценой в плане безопасности. Будет ли новый portage работать корректно с памятью в плане соблюдения требования W^X.

Сообщается о приблизительно 50-60% выигрыша при сборке «мира».

Речь идёт о выигрыше при расчёте зависимостей, а не при сборке пакетов.

Подправьте, пожалуйста.

Версия 3.0 выпилена

запилена

Даже на ЛОРе было заявлено о нескольких собственных попытках, которые кроме намерения переписывать никуда не сдвинулись.

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

Я немного не про это. Исходя из того что про этот portage понаписали разве go не будет лучшим выбором ? Почему разрабы пытались переписать это:

из другого источника

Подготовивший изменение разработчик также попытался реализовать прототип кода разрешения зависимостей на C++ или Rust, но задача оказалась слишком сложной, так как требовала портирования большого объёма кода, и, при этом, было сомнительно, что полученный результат стоил бы потраченных усилий.

Хотя Вы правы, это всего лишь мои мысли а в реале хз что там за кухня.

Да да, а неосведомленным эту путаницу нужно выяснять, так сказать, методом тыка)

Да да, а неосведомленным эту путаницу нужно выяснять, так сказать, методом тыка)

Да по-дурацки было написано в первом варианте новости.

Чтобы не было путаницы, можно писать «поддерживаются только версии 3.2 и более новые» или «поддерживаются только версии начиная с 3.2».

Речь идёт о выигрыше при расчёте зависимостей,

Извините я gentoo пробовал очень давно и уже забыл почти все :( А разве он зависимости каждый раз считает ? Ведь насколько я помню кол-во use флагов ограничено т.е. можно же составить таблицу всех зависимостей сразу. К примеру какая нибудь sqlite в локальном файле.

Каждый раз. Я пытался лет 10 назад использовать описанный в Вики подход с использованием базы данных для хранения дерева. Уж не знаю что именно в нём хранилось, но этот файл ещё сгенерить нужно после обновления дерева. Некоторые флаги у пакета несовместимы, некоторые требуют включения других. Зависимости от use флагов могут вообще не зависеть. Часть зависимостей тянутся из eclass. Нужно наложить настройки пользователя. Заметного прироста я тогда не заметил. Плюс всё это должно взаимодействовать со сторонними и локальными оверлями.

Когда дерево было мелким и portage более простым, он работал шустро. Сейчас он много делает сам, например, часто сам разруливает блокировки.

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

почему у меня тогда работает на 3.7?

https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/portage?id=bb3180edb5d310d5382bb3c0772c06be0b354806

Запилена. в 7 месяце.

https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/portage?id=a6fdfff938bc5fd2a0f8c4f9d969fc6123e23a71

Выпилена в 8 месяце ввиду выхода фиксов.

Не надо путать ветки и версии.

у меня и portage и eix в sqlite лежат.

Настроил лет 5 как, стало определенно шустрее.

Если внимательно посмотреть на вторую ссылку, то видно, что «выпилены» версии 3.0.0 и 3.0.1, но оставлена 3.0.2. То есть фраза «Версия 3.0 выпилена» неверна.

eix в sqlite лежат.

eix не занимается разрешением зависимостей и блокировок.

Да, признаю.

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

Pypy 3.6

Нет уж в основной ветке 3.6, 3.7.* только
А обычный бидон ужё 3.8 стабилизировался

На C++ уже есть Paludis, но работает он не шибко быстро и не все поддерживает. Go мертворожденный совсем.

Это только первый раз рассчет идет медленно, а вот второй раз уже все в памяти находится. База данных это шиндовс путь. Оверлеи подключаются легко через layman и в eselect есть рулежка ими. Обновляются вместе с деревом, но это не очень нужно большинству. Можно и без оверлеев жить. Просто после вычисления он раньше тупил подолгу вообще не обращаясь к жесткому диску и потому ввели это улучшение. Работает с версии питона 3.2, а для младших версий затычка. Впрочем системные сейчас это 3.6 - 3.8, так что это надо сильно налажать с выставлением текущей версии питона. 3.2 если и нужен может быть в fallback режиме.

отличная новость, ускорение хоть и небольшое всегда хорошо, обожаю portage, говорят это лучший менеджер пакетов в linux

я и писал что из основных реализаций не объявленных сдохшими вроде ниже 3.6 нет.

Зато с sqlite он работает быстрее, меня лично порадовало ускорение eix-sync.

А где почитать про возможности?

eix-sync вызывает emerge –sync + eix-update. Первый вызывает rsync, git pull, …., т.е. то, что настроено. Так вот git pull –depth=1 работает очень шустро, в отличии от rsync.

Его убрали из портежа, но кто мешает вернуть?

https://paludis.exherbo.org/

https://wiki.gentoo.org/wiki/Paludis

Предлагаете тянуть дерево из GIT?

Спасибо, посмотрел. Пока Pkgcore мне кажется более удобным но я его не тестировал, использую emerge

Это один из официальных способов сейчас. Работает шустро. Главное правильное зеркало выбрать. Правильное в том смысле, что не тянуть репу разработчиков (gitweb, одно из зеркал на github), а брать зеркало для синхронизации (специальное зеркало на github).

Ну косноязычность - очень распространенная проблема. Согласен, в первом варианте написано глупо.

Как станет многопоточным, так перестанет наверное.

Кто многопоточным станет? Питон? Не, треды там есть, но толку от них понятно, gil во все поля

Обсчет идет на одном ядре и это явный косяк портежа. Улучшить на 50-60% конечно здорово, но что это даст какому-нибудь атому с 4 ядрами по 1,1ггц? Или феномы, эфиксы, тредрипперы предыдущего поколения не смогут задействовать почти ничего. Вот есть тридриппер на 32 ядра например. Делим минуты на 32 и получаем секунды на обсчет.

Да какая разница, сборка всё равно больше займёт. Портедж, конечно, тормозной, но я не уверен, что разрулить зависимости в несколько потоков там тривиальная задача. А альтернативы чёт не взлетели.

Делим минуты на 32 и получаем секунды на обсчет.

А ты смешной

Но да, считать на одном ядре конечно не очень

Когда на 6 ядрах ждешь сначала около 20 минут мержа с uvDNaq world, а затем, выясняя зависимости противоречащих пакетов и их возможные новые версии тратим еще по 5 минут на каждый не кешированный запрос. Это очень помогло бы, особенно процам с не слишком быстрым однопотоком. То есть штеудовым атомам и большинству амд.

Да надуманная проблема. Даже если portage станет быстрее, да ещё с несколькими потоками, я особо не обдрочусь на это, особенно в несколько потоков.

А речь была не о чужом, а о моем мнении, и как видно я не один был бы менее надуман.

Хочется производительности, развивай другие менеджеры, портедж всегда будет консервативен.

Как знать. Вот надоест владельцам многоядерных компов ждать, так и разродится новой версией. Чтобы компилировать массу пакетов портеж ненужен. В Void например все происходит довольно шустро и все можно собрать из исходников. Так что есть вариант намного проще - перейти на Void. Тем более, что Musl, uclibc, x32 профили даже не переехали на профиль 17.1.