LINUX.ORG.RU

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

 , ,


1

0

Стабилизирован выпуск 3.0 пакетного менеджера Portage дистрибутива Gentoo. Из нововведений:

  • Удалена поддержка Python 2.7. Теперь поддерживается только версия 3.2 и выше.

  • Значительно ускорены вычисления за счёт оптимизаций и применения кэширования результата функций catpkgsplit и use_reduce. Сообщается о приблизительно 50-60% выигрыша при вычислении зависимостей.

>>> Подробности

★★★

Проверено: alpha ()

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

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

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

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

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

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

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

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

bryak ★★★★ ()
Ответ на: комментарий от anonymous

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

mx__ ★★★★★ ()
Ответ на: комментарий от bryak

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

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

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

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

anonymous ()

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

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

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

grem ★★★★★ ()
Ответ на: комментарий от mx__

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

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

grem ★★★★★ ()
Ответ на: комментарий от grem

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

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

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

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

mx__ ★★★★★ ()
Последнее исправление: mx__ (всего исправлений: 2)
Ответ на: комментарий от David_GL

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

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

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

wandrien ()
Ответ на: комментарий от grem

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

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

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

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

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

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

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от TheAnonymous

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 месяце ввиду выхода фиксов.

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

Slackware_user ★★★★★ ()
Ответ на: комментарий от Slackware_user

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

AnDoR ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от grem

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

anonymous ()
Ответ на: комментарий от Slackware_user

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

grem ★★★★★ ()
Ответ на: комментарий от Slackware_user

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

grem ★★★★★ ()
Ответ на: комментарий от upcFrost

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

anonymous ()
Ответ на: комментарий от anonymous

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

madcore ★★★★★ ()
Ответ на: комментарий от madcore

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

anonymous ()
Ответ на: комментарий от anonymous

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

madcore ★★★★★ ()
Последнее исправление: madcore (всего исправлений: 1)
Ответ на: комментарий от madcore

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

anonymous ()