Какой пакетный менеджер устанавливает пакеты параллельно?

Какова, по твоему, вероятность того, что при одновременной распаковке\настройке всё пойдёт не так и будет очень плохо?

(ЕМНИП, Portage умеет параллельную сборку и установку нескольких пакетов)

Не интересовался специально, но а вдруг maven так может, кто знает?

а если пакет 1 зависит от пакета 17 и 25, но по скольку 70 пакетов собираются параллельно, пакет 1 собрался быстрее пакетов 17 и 25, и разволился при настройке. Зависимости кстати в более сложные цепочки выстраиваются.

собираются

Не интересует.

Ну хорошо УСТАНАВЛИВАЮТСЯ, но есть же строгие зависимости. Вот если у тебя культей нет, а тебе нужно qtox воткнуть

Как отсутствие зависимости может помешать распаковать пакет и скопировать его содержимое в системную иерархию?

Но ведь время установки (на ssd-то) это капля в море по сравнению с временем скачивания (или там многогигабитка?), какой особо смысл? Теоретически-то идея правильная, но на практике особого прироста не будет, толку заморачиваться?

Но ведь время установки (на ssd-то) это капля в море по сравнению с временем скачивания

Нет, вполне сравнимые величины. Установка даже дольше бывает, как раз из-за последовательной обработки скаченного.

на практике особого прироста не будет

Будет.

Решение графа зивисимостей — задача NP. Решение графа зависимостей параллельно — лучше даже не начинать.

А что будет, если два пакета содержат один и тот же файл и решат его одновременно записать? Пусть этот файл будет последним, и они остальное уже распаковали.

два пакета содержат один и тот же файл

По-моему, такого в принципе не должно быть.

Ещё fsync() и барьеры фс отключи.

Что мешает все скаченные пакеты одновременно распаковать и записать в ФС?

Ничего не мешает. Но установка пакетов заключается не только в распаковке по фс. Но и в модификации баз данных пм. Которые очень уж не хочется потерять в самый неподходящий момент. А так уж исторически сложилось, что весь набор средств сохранения целостности баз данных пм опирается на то, что в данный момент времени только один процесс вносит изменения.

В таком случае будет ошибка хоть последовательно, хоть параллельно. Чтоб такого не было следят мейнтейнеры.

Что мешает писать изменения базы в какой-нибудь /var/tmp, а по завершении установки всех пакетов разом перенести эти изменения в базу?

два пакета содержат один и тот же файл

По-моему, такого в принципе не должно быть.

На практике сплошь и рядом (например, заголовки в multilib) и бэкенд пм умеет это обрабатывать, если у файлов совпадают атрибуты (mtime, права).

Прям сплошь и рядом? Не думаю.

Не думаю.

Я вижу.

Я пишу с системы, где libeatmydata.so засунута в LD_PRELOAD всей системе. И ничего, больше года полет нормальный. Правда, дело на ноуте, но для гроба все решается обычным UPS...

Не думаю

А следовало бы.

Приведите примеры таких файлов.

Заголовки от -dev{,el} от разных архитектур.

Судя по всему, какой-то очередной дебианотрэш. Сплошь и рядом, ога.

Все редхатовские, все дебиановские. Но можешь рассказать что multilib не нужен, если хочешь. Я отвечу, что мне SSD не нужен.

Тебе надо просто похакать установщик, чтобы он sync делал не после каждого пакета, а после всей связки. Так как запись всё равно идёт через write-back кеш, на sync'е как раз получишь параллельную запись.

Половина распаковалась, половина нет, блоб нвидии вызывает кернел панику и твоя система превращается в тыкву. Это уж не говоря о том, что изменения ты хоть и скопом, но ровно также последовательно в один поток будешь в базу лить с ровно таким же пенальти на скорость. Опять же, сколь-нибудь заметное ускорение на параллельной распаковке будет только на пакетах с небольшим количеством файлов, парочка каких-нибудь linux-source с кучей мелких файлов без проблем забьют тебе очередь даже на ssd.

Ну лан, разрешаю вам покинуть тред.

alexferman, твой пост похож на вопрос: есть ли пакетный менеджер от systemd ?

Так вот

beastie

лучше даже не начинать.

Половина распаковалась, половина нет, блоб нвидии вызывает кернел панику и твоя система превращается в тыкву.

Такие баги-глюки и при последовательной установке превращают систему в тыкву.

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

Чего это? У того же пакмана база это то же дерево каталогов с файлами. Пиши хоть во все сразу.

Portage/emerge, но не совсем параллельно. Можно параллельно ставить отдельные пакеты, но сам пакет и его зависимости он будет ставить последовательно, так как ряд зависимостей всё равно будут ждать установки своих зависимостей.

+1. Если мне как к разработчику дали бы такое задание я бы попытался уговорить не делать такое. Хорошо, допустим будем параллельно накатывать пакеты, но если зависимый пакет не скачался, нам же нужно будет все откатить назад, все изменения в ФС, а иначе у нас будут битые зависимости. Более того есть несовместимые пакеты, нам нужно обратно вернуть то, что было замещено пакетами у которых зависимости не удалось удовлетворить. Но допустим скачивание повисло и пользователь нажал пресловутый Ctrl+C или села батарея... я прямо вижу этот страшный баг на багтрекере... брр. Значит нужно сделать так, чтоб при следующем старте у нас запустился бы пакетный менеджер, восстановив последние свое состояние все исправил тот хаос на ФС. Но... теперь нам нужно сделать так чтоб система загрузилась(!), значит мы должны разделить пакеты на те которые можно накатывать параллельно и те без которых система не загрузится...

... после 5 лет разработки наконец вышел наш продукт от которых плюются меинтейнеры дистрибутива в котором его таки начали использовать.

Если мне как к разработчику дали бы такое задание я бы попытался уговорить не делать такое

А я бы сказал не тупить и делать то, что сказано))

Такие баги-глюки и при последовательной установке превращают систему в тыкву.

Нет. При последовательном теряется только последняя транзакция. По крайней мере в deb и rpm. И если для deb иногда надо сделать после сбоя перед продолжением установки apt-get -f install или dpkg configure -a, то rpm просто ругнётся на старый lock и продолжит, как ни в чём ни бывало.

Да хоспаде, сделать подстраховку это вообще не проблема. В конце концов, 2017 год на дворе, есть снапшоты.

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

что-то мне это напоминает 😄

А я бы сказал не тупить и делать то, что сказано))

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

Да хоспаде, сделать подстраховку это вообще не проблема. В конце концов, 2017 год на дворе, есть снапшоты.

Ради чего? Ради экономии двух секунд на распаковке при том, что на скачивание всё равно уйдёт минута, плюс хуки, которые уж точно последовательно будут?

Там не о двух секундах речь, а о десятках секунд.

А вообще у меня есть идея «пакетного менеджера», который не то что параллельно, а вообще (*почти) ничего не распаковывает. Вместо пакетов запилить SquashFS-образы. Установка их просто монтирует, файлы из /etc и /var (если таковые вдруг содержатся в пакете) после этого копируются в read-write раздел (при этом копировать или распаковывать основную часть, которая в /usr, никуда копировать или распаковывать не требуется), затем это всё с помощью aufs просто вместе монтируется в корень, либо просто симлинкается. В чём-то похоже на подход, используемый в NixOS и имеет все те же преимущества вроде возможности иметь установленными несколько версий одной программы или библиотеки, но при этом ещё и уменьшает время установки, сохраняет место на диске в 2+ раза (поскольку в кэше в обычных дистрах всё равно файлы пакетов лежат, а здесь и файл пакета и установленный он же — одно и то же, лишнее место на диске не занимается, плюс сжатие).

То ли у тебя SSD какой-то не такой, то ли пакеты по 100500 мелких файлов (и тогда параллельная установка не поможет), то ли хз, но у меня редко апдейт занимает больше десяти секунд после скачивания пакетов, а вот оно да, занимает десятки. Надо будет более точно засечь, когда сразу пара десятков пакетов прилетит. Сейчас нечего обновлять, а тестить на одном-двух пакетах нет толку.

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

По какой причине? Ну загружаться я ещё могу понять — монтирование не моментальное, но работать-то наоборот должно быстрее. Или там какой-то оверхед от большого (сотни, а то и тысячи в теории) количества маунтпоинтов? На практике я такое, конечно же, не проверял. С отдельными программами или собраниями файлов это очень даже хорошо работает.

А вы знаете... можно сделать, только нужно место в корне или в том разделе куда ставить. Можно параллельно распаковывать в любое место на ФС и если все хорошо закончилось сделать move для каждого файла.

только нужно место в корне или в том разделе куда ставить

А если корень с /bin на одном разделе, /usr на другом, /var на третьем, /etc на четвёртом? «Ненужно и мешает великой миссии сохранения 2 секунд при распаковке, запретить!»? Поттеринг-вей какой-то.

А вообще, зачем морочиться с образами, монтированием, и т.д., если есть appimage? Никакой вам установки, кликнул и пожалуйста

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

Там внутри SquashFS тоже. Спереди прилеплен бинарник, который его монтирует с оффсетом с помощью FUSE. Можно примонтировать без FUSE руками, указав оффсет.

Portage

Ну а для библиотек это вообще ппц. Представьте, как будет запускаться та же Plasma, если каждую библиотеку нужно будет ещё монтировать.

Ну в той идее выше они заранее смонтированы при старте системы. Все установленные пакеты. Не знаю, впрочем, как это на практике себя поведёт, как быстро оно всё будет монтироваться (это делается один раз при запгрузке системы, ну и при установки/удалении пакета примонтирование/отмонтирование) и будет ли какой-то оверхед от того, что точек монтирования сотни, я не знаю. Просто вот такая мысль посетила, когда увидел, насколько SquashFS хорош (особенно для игр).

portage

hint: для тех, кто не любит собирать, существуют бинарные пакеты