Pacman в несколько потоков

Оно вообще пакеты не компиляет. Это менеджер собранных пакетов.

Ты на скриншоте у ТСа где увидел makepkg?)

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

Fira Code

хороший шрифт - похож на consolas, пользовался одно время им, но все равно на consolas вернулся.

шрифт молодцом, аккуратно ужался, и всё ещё можно что-то прочитать

вот месье знает толк - ничто лучше consolas это сделать не сможет

просто не менял

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

По дефолту мб сделали, но в pacman.conf оно есть уже очень давно.

Хоть когда-то баян пригодился. :)

dnf плох хотя бы федорой. Я имел в виду rpm который по крайней мере используется в дистрибутивах.

ничеси у тебя пельмени на экране

Было бы это норм фичей, если бы зеркало тротлило загрузку в один поток до 10 метров в секунду, и ты могу бы поставить потоков 10, чтобы кратковременно утилизировать свой гигабитный инет при обновлении системы.

А такой пись-пись метр в секунду, какой смысл, качаешь ты последовательно или параллельно? Экономишь время только на установку нового соединения между пакетами.

Я уж подумал про эпичную игрушку, а тут школорач.

Для меня дебиановский достаточно хорош.

А ты сейчас о dpkg или об apt?

И что не так с rpm?

Он всегда так работал

ну не всегда, а только последние 5 лет

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

если в системы сборки не лезть — ну пакет как пакет. что apt/dpkg, что pacman/alpm.

Тормозной и никакой в управлении зависимостями.

Об aptitude/dpkg или synaptic/dpkg

О, про зависимости.

В экосистеме rpm-дистрибутивов, если что-то зависит от libblabla.so.3, то оно зависит от libblabla.so.3.

А не от воображаемой херни, как в Дебиане.

Шрефты — топ. С низу.

Зачем тебе консолас, если есть ubuntu mono? Зачем тебе letterSpace, если есть Iosevka!?

Почему? Есть же Nix.

никакой в управлении зависимостями

А где это сделано лучше, чем в rpm? Очень интересно. Не говорите только, что в дебиане.

В Slackware у меня никогда ПМ не выдавал ошибки о сломанных зависимостях, и никогда не зависал в вечном адском цикле при удалении сломанного пакета.

Это всё хорошо в рамках слаки, где нет репозитория и весь дистр монолитный по сути. Но для большой пакетной базы это не работает. Даже в salix пришлось прикрутить зависимости. Ну и в sbopkg тоже есть примитивное разрешение зависмостей через очередь. Иначе было бы напряжно раскручивать дерево вручную. Всё это зачатки пакетного менеджера на самом деле. Если бы у слаки было сообщество, оно породило бы что-то вроде пакмана в итоге.

Но для большой пакетной базы это не работает

У Slackware довольно большая пакетная база. Если посчитать офф.репозиторий, slackbuilds и alienbob. У Debian 10 пакетов всего в два раза больше примерно, но учитывая как они разбиваются...

Если бы у слаки было сообщество, оно породило бы что-то вроде пакмана в итоге.

Сомневаюсь, Патрик напрямую рассказывал о проблемах ПМ, и упомянул что каждый пользователь ПМ с ними скорее всего встречался, что есть чистая правда, вон у hobbit есть статья какие файлы в реестре нужно чистить что бы dpkg мог продолжить работать в случае со сломанным пакетом. В Slackware такое сложно представить, даже если slackpkg сломался, installpkg работать то будет.

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

Мало кто лучше дебиана. Ну генту, ну вот Никс наверное. От любого rpm- и разных маргинальных пакетников типа void я только плевался и недоумевал. С Арчем к сожалению сравнивать не могу. Приоритеты реп, блокировки, чистка зависимостий, ручное разруливание, самопочинка реализованы?

Ничего непонятно. Какой механизм не позволит что?

Приоритеты реп, блокировки, чистка зависимостий, ручное разруливание, самопочинка реализованы?

Что это за страшные слова? Какая самопочинка? Арч без костылей работает, пардонте.

Героически решать проблемы, которые без Дебиана бы даже не существовали - не наш путь.

А где это сделано лучше, чем в rpm?

В том-то и дело, что нигде, получается.

Если бы в Арче зависимости прописывались на уровне имён so-файлов, я бы сказал, что в Арче сделано плюс/минус на том же уровне, даже не смотря на то, что по другим возможностям тоже можно докопаться. Но это существенный недостаток, поэтому в Арче - хуже, чем в rpm.

зачем тебе жопа если палец есть? ubuntu mono ни капли не похож на consolas и с Iosevka такая же фигня.

А чем salix плох? Imho он и есть то сообщество слаки - ибо софт 1:1, только с зависимостями.

Компиляет makepkg, как и другие обертки над системами сборки пакетов, он умеет указывать всякие флаги компилятора, в том числе может указывать системе сборки, что работать надо в многопоточном режиме. Но вот одновременно собирать сразу несколько пакетов он не может (или я чего-то не знаю) :)

Просто makepkg в силу своего предназначения не может такое. Его задача - сборка пакета. Одного пакета. То есть он разбирается во внутренней кухне сборки пакетов.

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

У меня это таким костылем решается, например: https://github.com/sde-gui/pacman.sde-git

Ну, такое не так уж часто и нужно, у меня набор пакетов уже устоялся, что-то новое редко собираю :)

При таком разрешении зависимостей как ты будешь указывать «зависит от какого нибудь ssh-сервера» или «любая реализация openGL»?

Ну а когда пакетник навернётся, найдёт сбойные пакеты и сможет их переустановить?

которые без Дебиана бы даже не существовали

Сбои ФС и питания существуют только в дебиане? Божественный арч выполняет распаковку архива на ФС и регистрацию файлов в БД мгновенно и атомарно? Кривых пакетов с неразрешимыми зависимостями в арче я так понимаю тоже не бывает?

Арч без костылей работает, пардонте.

А не в Арче советуют читать арче-новости перед обновлением?

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

А не в Арче советуют читать арче-новости перед обновлением?

А в Дебиане не советуют? Так это об уровне ответственность мейнтейнеров Дебиана говорит, при чем не в их пользу.

При таком разрешении зависимостей как ты будешь указывать «зависит от какого нибудь ssh-сервера» или «любая реализация openGL»?

«При каком» разрешении? При чем тут ssh-сервер?

Я писал про зависимости от shared objects. Которые в дебиане сделаны через окаменевшее говно мамонта.

ssh-сервер - это shared object? Нет? Тогда при чём тут это?

А в Дебиане не советуют?

Я такое

update may need manual intervention

только в Арче видел. Очень ответственно, да.

Ну а когда пакетник навернётся, найдёт сбойные пакеты и сможет их переустановить?

Кирилл, вы сейчас говорите на одном вам понятном языке. Пакетник навернётся? Как? На пол с полки? Окей, допустим, навернётся. Тогда как и кто «найдёт сбойные пакеты», если пакетник сдох?

А если не «навернётся», то pacman -Qkk. Видимо, об этом шла речь.

«Само» никогда ничего не происходит. У любого сбоя есть причина, а из причины следуют действия по решению проблемы. Волшебной кнопки «сделать хорошо» нет нигде. Разница - в уровне прозрачности и в том, насколько «умная» ОС пытается мешать умному админу.

Сбои ФС и питания существуют только в дебиане? Божественный арч выполняет распаковку архива на ФС и регистрацию файлов в БД мгновенно и атомарно?

Божественный арч не сносит половину системы при обновлениях и не выполняет при обновлениях кучу мутных скриптов, написанных левой лапой пьяной курицы. Я уже как-то приводил статистику, сколько всего в арче есть кастомных pre/post-install скриптов. ЧСХ, в дебиане такую статистику даже получить невозможно простым способом. Но там всё печально.

Поэтому ситуации «случилось незнамо что» на практике не бывает. Если вдруг питание пропало при обновлении, то как и любой линукс, всё чинится из chroot с флешки. При чём чинится в разы проще того же дебиана с его безумной системой управления пакетами.

А атомарных обновлений пока не завезли, да.

Кривых пакетов с неразрешимыми зависимостями в арче я так понимаю тоже не бывает?

За 15 лет не попадалось. Но даже если такой окажется в репе, то как он окажется установленным «с неразрешимыми зависимостями»? pacman его просто не поставит. Если конечно не прилагать к этому специальных усилий.

Очень ответственно, да.

Да, это более ответственно, чем пытаться исполнять на пользовательской машине скрипты-угадайки, которые «могут» сделать что-то нужное при удачном стечении обстоятельств. (А могут и не сделать.)

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

Напоминаю, речь идёт о роллинге. Где нет никаких чётких раз и навсегда установленных соглашений - любое, что сейчас кажется логичным, через два года может потребовать замены. И там постоянно идёт процесс переработки пакетной базы. Немного меняются нейминги, немного меняется деление на пакеты, какие-то системные компоненты постепенно приезжают, а какие-то устаревают и выпиливаются. И всё это в таком виде существует уже очень много лет. Весьма стабильно. Весьма надёжно. У меня вот на машинах Арч уже 15 лет используется.

При чем на одном из ноутов пережил без переустановки миграцию с 32 на 64 бита и с инит-скриптов на systemd.

Ну пакман же позволяет технически конкретную версию библиотеки прописать в зависимости. И с другой стороны, позволяет прописать provides=чтототам, что ещё нужно?

При таком разрешении зависимостей как ты будешь указывать «зависит от какого нибудь ssh-сервера» или «любая реализация openGL»?

Вручную прописывать как везде.

Не знаю насчет сообщества. Там пользователей как бы ни меньше, чем у самой слаки. Но зависимости кропотливо прописали, да. Без зависимостей минимальную систему проблематично сделать, а full install будет уже даже в Salix слишком жирный.

У Slackware довольно большая пакетная база. Если посчитать офф.репозиторий, slackbuilds и alienbob.

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