Господи, какое ж это щастье, когда менеджер пакетов не на питоне!

Полагаю, речь про более сложную логику расчёта зависимостей с учётом USE-флагов и т.п. Полагаю также, что говнопитон (как и любая говнодинамическая типизация) к расчётам не приспособлена в принципе, и будучи переписанной на C/C++, эта логика отрабатывала бы тоже мгновенно, и юзер вместо одного мгновения не заметил бы два.

будучи переписанной на C/C++, эта логика отрабатывала бы тоже мгновенно, и юзер вместо одного мгновения не заметил бы два.

Уже переписывали (Paludis). Насколько я знаю, он не был значительно быстрее в разрешении зависимостей.

Кстати, +1

Уже переписывали (Paludis). Насколько я знаю, он не был значительно быстрее в разрешении зависимостей.

Значит, базу надо также бинарную.

А как pacman решает опциональные зависимости?
Там это как настраивается?

Полагаю, речь про более сложную логику расчёта зависимостей с учётом USE-флагов и т.п.

и т.п.

Там дело не только в питоне. Там всю архитектуру менять надо.

Если руки из задницы, из любого языка можно сделать bash.

А как их надо решать?

А как pacman решает опциональные зависимости?

По умолчанию они не ставятся. Но есть костыль.

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

По дефолту опциональные пакеты — опциональны.

Рекомендации вручную ставить.

Сам pacman только информирует о них.

Хотя наверняка это доделано в куче оберток для него.

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

Это опции зависимостей пакета, а не сборки.

Ну если есть программа, поддерживающая Qt и GTK. У тебя стоит обе библиотеки. Как pacman выбирает способ сборки?

И в принципе опция аналогичная emerge --with-bdeps реализуется предельно тупо, но в pacman -hS не видать. И пох: лично я никогда не понимал, нафига она нужна, и никогда не использовал. Особенно если этих опциональных зависимостей – вагон и маленькая тележка, а тебе если и нужно из них чего, то 1-2.

Арч не source-based.

Понятия опциональной зависимости времени компиляции в нем нет.

Предполагается, что если собирает билд-сервер, он собирает полный фарш.

А если пользователь, то пользователь вручную pkgbuild отредактировать может.

Никак. https://github.com/archlinux/svntogit-community/blob/packages/zathura/trunk/P...

тогда не совсем ясно сравнение pacman с emerge

Пакман ничего не выбирает, это менеджер пакетов, а не сборочная система.

Гента головного мозга, похоже =)

Это к ТСу)

Ну понятно, к кому же ещё. =)

Можно два пакета с разной сборкой сделать. Типа yoba-qt, yoba-gtk.

Ну если есть программа, поддерживающая Qt и GTK. У тебя стоит обе библиотеки.

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

Обычно так и делают.

Человек только узнал, что зависимости могут вычисляется того, как вы успеете сделать кофе, дайте ему по радоваться. :)

то есть смысл в том, что pkgbuild проще устроен, чем ebuild? в общем.

Да. Он простой как палка. Этим и хорош, ибо во что превратился apt мне больно смотреть. Почему оно такое жирное и встратое!?

Почему вы все путаете пакетный менеджер и сборочную систему в одну кучу?

Хотим и путаем. Чего докопался?

Что? Он до сих пор может пол системы снести по приколу.

а sbopkg это сборочная система?

Apt пакетный менеджер. Pkgbuild сборочный скрипт на баше. Какая связь? Никакой.

О_о Это от слаки что-то. В слаке не шарю.

ну зависимости прописаны в обоих.

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

А что, где-то кроме Альта, изпользуют нестандартные комбинации сборки и пм?

Вообще я считаю формат pkgbuild — это лучшее, что случалось в мире сборки пакетов под линукс.

Вот я тут сегодня программу опакетил:

pkgname=tke
pkgver=3.6
pkgrel=1
pkgdesc="A full-featured source code editor with a minimalist UI. Implemented in Tcl/Tk."
url="http://tke.sourceforge.net/"
arch=('any')
license=('GPL')
depends=('tcl>=8.6' 'tk' 'tclx' 'tcl-vfs' 'tkdnd' 'tklib' 'tcltls')
source=("https://sourceforge.net/projects/tke/files/3.6/tke-3.6.tgz" "fix-install-tcl.diff")
md5sums=('88f15fa11d714377b05a1bf95e5d697a'
         '40e4c07df2cf79c4052d3e1d446740e4')
sha1sums=('b52de6a55a5a7f8bd1c7256e6c3cabf7f381615d'
          '30aecf490c31a227bf6fcde7e14d78cb96a9a419')

prepare() {
    patch -uN -d "$srcdir/${pkgname}-${pkgver}" < fix-install-tcl.diff
}

build() {
    true
}

package() {
    cd "$srcdir/${pkgname}-${pkgver}"
    export DESTDIR="$pkgdir/usr"
    ./install.tcl

    cd "$pkgdir"

    sed -i "s#$pkgdir/usr/#/#" usr/bin/tke usr/share/applications/tke.desktop

    if grep -r "$pkgdir" . ; then
        false
    fi
}

Всё же предельно понятно. (Ну, не считая костылей в package(), но это автор программы виноват, что у него нормального make install нет.)

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

Под RPM проще, конечно, опакетить, чем под дебиан, но тоже морока. Отдельный синтаксис. А смысла никакого. Переменные вписать можно тупо на bash.

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

Это очень слабо связанные между собой подсистемы.

(Хотя в дебиане общий маразм охватил всё, там что сборка через задницу сделана, что установка. Но это дебиан, там без задницы никуда.)

(Хотя в дебиане общий маразм охватил всё, там что сборка через задницу сделана, что установка. Но это дебиан, там без задницы никуда.)

Сборка мне и правда показалась переусложнённой (не осилил), а вот с установкой всё просто - это просто распаковка файлов (с учётом какой куда распакован) + скрипты-хуки preinstall postinstall по желанию.

а вот с установкой всё просто - это просто распаковка файлов (с учётом какой куда распакован) + скрипты-хуки preinstall postinstall по желанию.

Это в арче.

А в дебиане это еще и всякие dpkg --configure, во время которого МОЖЕТ ВНЕЗАПНО ВЫЛЕЗТИ ДИАЛОГОВОЕ ОКНО С ПСЕВДОГРАФИКОЙ и ДЕБИЛЬНЫМИ ВОПРОСАМИ. И выбор «приложений по умолчанию». И я боюсь вспомнить, что там еще.

И еще, тормозааааа. Как они умудрились сделать тормоза тупо при распаковке архивов? Не знаю…

Ну ок. Почему тогда во всех форках арча ничего другого не используют?

dpkg --configure это и есть вызов хук-скрипта. Вопросы и правда местами дурацкие задаются (это в самих пакетах прописано).

«Приложения по умолчанию» - там такого нет.

Потому что всё и так хорошо.

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

А почему все хорошо? Не потому ли, что их разрабатывали одни и те же люди в расчете на одну и ту же концепцию?

dpkg –configure это и есть вызов хук-скрипта. Вопросы и правда местами дурацкие задаются (это в самих пакетах прописано).

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

«Приложения по умолчанию» - там такого нет.

man update-alternatives

alternatives это не совсем «по умолчанию», ну не суть, я так и подозревал что речь про них. И что с ними не так? Ты установил три версии gcc, кто-то же должен решить к какой из них команда gcc будет вести? Или установил три window manager'а, надо же выбрать какой из них будет запускаться по дефолту?

Ну, alternatives делают то же самое, только универсально а не только для джавы. Возможно, универсальность немного повредила понятности.

Ты установил три версии gcc, кто-то же должен решить к какой из них команда gcc будет вести?

Если я установил три gcc, я тебе зуб даю: я категорически НЕ хочу, чтобы система даже пыталась начинать думать в сторону возможного «переключения компиляторов».

Один из них, наверняка, кросскомпилятор на ARM, а второй вообще может быть тестовой сборкой из транка апстрима.

Целая сраная подсистема в составе APT существует для решения несуществующих проблем.

Или установил три window manager’а, надо же выбрать какой из них будет запускаться по дефолту?

По чьему «дефолту». Схерали пользовательские настройки тащить в общесистемный дефолт?

Открой для себя /usr/share/xsessions/.

И что с ними не так?

С ними не так примерно всё.

Хотя дебианщикам, привыкшим к тому, что «Ты хочешь удалить firefox? Ну вот тебе тогда chromium. ПОТОМУ ЧТО В СИСТЕМЕ ДОЛЖЕН БЫТЬ КАКОЙ-ТО БРАУЗЕР!», не понять…

Ты установил три версии gcc, кто-то же должен решить к какой из них команда gcc будет вести?

Если я установил три gcc, я тебе зуб даю: я категорически НЕ хочу, чтобы система даже пыталась начинать думать в сторону возможного «переключения компиляторов».

+ очень много. при написании gcc должен запускаться gcc прописанный для этого проекта или выдаваться command not found

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

Он до сих пор может пол системы снести по приколу

Каким образом? Давно починили же.

А в дебиане это еще и всякие dpkg –configure, во время которого МОЖЕТ ВНЕЗАПНО ВЫЛЕЗТИ ДИАЛОГОВОЕ ОКНО С ПСЕВДОГРАФИКОЙ и ДЕБИЛЬНЫМИ ВОПРОСАМИ.

ОМГ, ну выставьте приоритет по умолчанию на максимум, чтобы только критические вопросы остались: dpkg-reconfigure debconf.

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

Всем рекомендую!

И еще, тормозааааа. Как они умудрились сделать тормоза тупо при распаковке архивов? Не знаю…

Ну конечно, если поубирать все вызовы fsync(), то будет быстрее, ага. За счёт снижения надёжности, правда.

Ну и если это вас так тревожит, то и это можно отключить: см. опцию dpkg --force-unsafe-io.

Столько лишних движений

Это сейчас пользователь Arch сказал, или мне показалось?

Целая сраная подсистема в составе APT существует для решения несуществующих проблем.

Вы в курсе, что есть несколько реализаций awk? telnet? nc? vi? Для каждой отдельный костыль делать? Или же всё-таки сделать универсальную систему, а не свой набор костылей и подпорок для каждого отдельного случая?

И да, с хера ли alternatives — в составе APT? Вы там ничего не попутали?

Нет, тебе не показалось.

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

Я за 20 лет успел попользоваться FreeBSD, Red Hat, Mandrake, Suse, Debian, Ubuntu, немного Gentoo… что еще? Вроде всё из того, что стояло на десктопе на постоянной основе какое-то время.

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

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

Пакетирование софта - одно удовольствие.

Всё время новейший софт.

Удобный пакетный менеджер с короткими ключами. И быстрый при том.

Никаких сраных падений говносервисов на пустом месте, как в убунте, когда в ней постоянно в логи срали написанные кривой пяткой Каноникла скрипты на питоне.

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

Так что однозночно Арч для дома и CentOS/RHEL/Alma для сервера. Колупайтесь со своим аптом сами.

Спасибо за внимание =)

Вы в курсе, что есть несколько реализаций awk?

Я же говорю, решение несуществующих проблем.

Просто каждый день переключаю симлинк /usr/bin/awk с gawk на nawk и обратно. Самая востребованная операция при управлении конфигурацией системы.

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

Это сейчас пользователь Arch сказал, или мне показалось?

ROFL :))) Два чая и два наполеона двоим господам вон за тем столиком! :)))

Наполеоны лучше есть с кофе, я гарантирую =)

Ок, 1 чай, 1 кофе, 2 наполеона. :)

:-)

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

Я вот пользуюсь Debian 11 лет уже, и для меня именно этот дистрибутив на данный момент является оптимальным с точки зрения наиболее важных для меня критериев: стабильности и предсказуемости. Я могу быть уверен, что установка очередного обновления не сломает мне нафиг что-нибудь важное и не заставит колупаться в системе в то время как работа горит. Один раз настроил — и в следующий раз придётся на это отвлечься лишь через 2 года для обновления на новую версию.

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

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

Каждому своё.

Просто каждый день переключаю симлинк /usr/bin/awk с gawk на nawk и обратно. Самая востребованная операция при управлении конфигурацией системы.

А вы каждый день ставите несколько реализаций awk? Ибо только в этом случае система альтернатив хоть как-то становится заметна, и то лишь выводом пары строчек во время установки.

И да, в alternatives переключаются не только ссылки на бинарь, но и man awk будет указывать на правильную версию awk.

А вы каждый день ставите несколько реализаций awk?

Вот и мне интересно, кто все эти люди, которые не просто ставят несколько реализаций awk, а еще и непременно им надо, чтобы именно /usr/bin/awk указывал на что-то отличное от gawk.

Простой export PATH="$HOME/bin:$PATH" их чем-то не устраивает.

Вот и мне интересно, кто все эти люди, которые не просто ставят несколько реализаций awk, а еще и непременно им надо, чтобы именно /usr/bin/awk указывал на что-то отличное от gawk.

Повторяю: это универсальная система, которую можно использовать для решения всех таких ситуаций. Вот, например, Nvidia ставит свою реализацию GLX — в Debian между ней и системной можно переключаться с помощью alternatives. Пример с компиляторами вам тоже уже приводили. И таких примеров достаточно много, чтобы вместо того чтоб городить по костылю на каждый такой случай просто запилить одну систему с единым интерфейсом, которую смогут использовать как разработчики, так и пользователи.

Простой export PATH=«$HOME/bin:$PATH» их чем-то не устраивает.

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

Повторяю: это универсальная система, которую можно использовать для решения всех таких ситуаций. Вот, например, Nvidia ставит свою реализацию GLX — в Debian между ней и системной можно переключаться с помощью alternatives. Пример с компиляторами вам тоже уже приводили. И таких примеров достаточно много, чтобы вместо того чтоб городить по костылю на каждый такой случай просто запилить одну систему с единым интерфейсом, которую смогут использовать как разработчики, так и пользователи.

Ерунда какая. Дубовое переключение симлинков теперь называется «механизм альтренатив».

«Пакет XYZ конфликтует с установленным пакетом ABC. Удалить ABC? [д/н] _»

Вот и весь механизм альтернатив.

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

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

универсальная система, которую можно использовать для решения всех таких ситуаций.

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

Но эту задачу сейчас решает докер. А на уровне пакетного менеджера ни одна ОС эту задачу не решает.

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

Вот и вместо конфигурации, которая управляется файлами конфигурации зачем-то присобачили механизм симлинков и навертели на него сверху ненужных функций типа «браузера по умолчанию».

«Пакет XYZ конфликтует с установленным пакетом ABC. Удалить ABC? [д/н] _»

Вот и весь механизм альтернатив.

Ога. Ставишь такой себе clang, а система тебе: удалю-ка я gcc…

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

Все эти упоминания про симлинки на альтернативы в дебиане… А там механика сильно отличается от гентушного eselect?

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

Вас то в KISS бросает, то в докеры и прочие кубернетесы…

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

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

Как научитесь официально поддерживать больше чем полторы архитектуры — приходите.

Хорошо рассуждать о сложности системы, не понимая, откуда эта сложность взялась и зачем нужна…

Ога. Ставишь такой себе clang, а система тебе: удалю-ка я gcc…

Такое даже гипотетически только в дебилиане возможно. Ну никак же не решить, кто будет предоставлять cc и c++.

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

Не переживай, портить твою помойку никто не полезет. Нахлебались еще в 00-х.

Альтернативы переключают реализации в рамках системы.

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

Вместо этого оппонент порвался и передложил сделать gcc и clang конфликтующими пакетами. Ну дебиан как он есть.

Как научитесь официально поддерживать больше чем полторы архитектуры — приходите. Хорошо рассуждать о сложности системы, не понимая, откуда эта сложность взялась и зачем нужна…

Ооо, теперь архитектуры мешают избавиться от бесполезных симлинков или сделать нормальный способ сборки пакетов, хотя бы как в Void, ну или хотя бы как в той же Генте. =)

А там механика сильно отличается от гентушного eselect?

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

В alternatives пакеты устанавливают себя в качестве альтернатив некоторого объекта (например, c99), и указывают, какие файлы использовать в этом случае. /usr/bin/c99 (и соотв. man-страницы) являются ссылками на /etc/alternatives/*, которые в свою очередь уже указывают на реальные файлы, а управляется это всё командой update-alternatives:

$ sudo update-alternatives --config c99
There are 2 choices for the alternative c99 (providing /usr/bin/c99).

  Selection    Path              Priority   Status
------------------------------------------------------------
* 0            /usr/bin/c99-gcc   20        auto mode
  1            /usr/bin/c99-gcc   20        manual mode
  2            /usr/bin/clang     10        manual mode

Press <enter> to keep the current choice[*], or type selection number: 

Можно выбрать auto, и будет использоваться альтернатива с наивысшим приоритетом, а можно выбрать конкретную реализацию, и этот выбор останется неизменным при установке других пакетов/обновлении системы.

Причём используется эта система не только в Debian и производных, но и, например, в дистрибутивах под крылом Red Hat: RHEL, Fedora, …

Ну внешне похоже, только без auto.

Сборка пакетов здорового человека: https://github.com/void-linux/void-packages/blob/master/srcpkgs/gmp/template

45 понятных cтрок шел-скрипта.

Сборка пакета курильщика: http://deb.debian.org/debian/pool/main/g/gmp/gmp_6.2.1+dfsg-1.debian.tar.xz

140 килобайт мутотени и заклинания чёрной магии в debian/rules в виде мейкфайла. Мейкфайла, Карл. Они бы еще брейнфак выбрали.

Вместо этого оппонент порвался и передложил сделать gcc и clang конфликтующими пакетами. Ну дебиан как он есть.

Хоспади, какой же бред… Это же вы сами, блин, предложили так сделать: Господи, какое ж это щастье, когда менеджер пакетов не на питоне! (комментарий)! «Вот и весь механизм альтернатив», ага.

И пример с gcc и clang был мной приведён ровно для того, чтобы показать неадекватность такого предложенного вами решения!

А вы теперь пытаетесь сделать вид, что это типа я выступил за этот бред, а не вы…

Такое даже гипотетически только в дебилиане возможно. Ну никак же не решить, кто будет предоставлять cc и c++.

«в дебилиане», ага. И кто же тут на самом деле порвался, а?

«в дебилиане», ага.

Адекватней себя веди, и не будет дебилианов. Тут не институт благородных девиц, но и не двач.

Хоспади, какой же бред… Это же вы сами, блин, предложили так сделать

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

45 понятных cтрок шел-скрипта.

Ну да, ну да. Без changelog (который занимает большую часть размера в Debian), без разных опций сборки под разные архитектуры, без возможности сборки не под хост-систему…

Ну и привели пакет, использующий старую систему сборки вместо dh с overrides.

RHEL, Fedora

Нет там такого маразма как выбор компилятора.

ld	auto	/usr/bin/ld.bfd
mta	manual	/usr/sbin/sendmail.exim
mysqlbug	auto	/usr/lib64/mysql/mysqlbug
java	auto	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64/jre/bin/java
jre_openjdk	auto	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64/jre
jre_1.8.0	auto	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64/jre
jre_1.8.0_openjdk	auto	/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64
pax	auto	/usr/bin/spax
print	auto	/usr/bin/lpr.cups
google-chrome	auto	/usr/bin/google-chrome-stable

Адекватней себя веди, и не будет дебилианов

Ну конечно. «Дебилиан» написали вы — а адекватнее вести себя должен я. Разумеется.

Знаете что — разговаривайте так сами с собой, пожалуй.

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

Какой ещё конфликт имён? Вам слово provides знакомо?

Есть условный /usr/bin/c99, есть несколько пакетов, которые предоставляют функциональность компилятора C99 — каким образом, по-вашему, должно управляться, какой именно пакет будет предоставлять эту ссылку?

Нет там такого маразма как выбор компилятора.

Во-первых, вопрос не конкретно в компиляторе — это лишь один из примеров использования.

Во-вторых, почему какую-нибудь java выбирать с помощью альтернатив можно, а компилятор по умолчанию — нельзя? Кто это сказал?

без разных опций сборки под разные архитектуры, без возможности сборки не под хост-систему…

войд поддерживает кросс-компиляцию, все собирается в chroot

https://github.com/void-linux/void-packages/blob/master/srcpkgs/gcc/template

Без changelog (который занимает большую часть размера в Debian)

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

без возможности сборки не под хост-систему…

https://wiki.voidlinux.org/Cross_Compiler

без разных опций сборки под разные архитектуры

Если открыть ебилд gmp в портаже, там даже под сборку на Darwin предусмотрен отдельный патч. И всё это на нормальном шел-скрипте без мейк-магии.

Есть условный /usr/bin/c99

Условным компилятором можно собрать только условную программу. =)

каким образом, по-вашему, должно управляться, какой именно пакет будет предоставлять эту ссылку?

CC=clang ./configure --prefix=$HOME/builds/my-cool-app

Во-вторых, почему какую-нибудь java выбирать с помощью альтернатив можно, а компилятор по умолчанию — нельзя? Кто это сказал?

Потому что java это рантайма кусок для кучи продуктивного ПО, и если у тебя сервер (или докер-контейнер) нужен, чтобы крутить это ПО, то просто ставим нужную версию джавы и всё.

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

Еще больший маразм выбирать альтернативой «браузер по умолчанию» или оконный менеджер. Это вообще пользовательские настройки.

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

Бла-бла-бла. Действительно, зачем вести документацию изменений пакета? — и так сойдёт!

Если открыть ебилд gmp в портаже

А если открыть сценарий NSIS…

И всё это на нормальном шел-скрипте без мейк-магии.

Разработчик, который плохо знает make… (И который ещё и считает bash-скрипты значительно лучшим выбором…)

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

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

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

Наличие нескольких компиляторов вообще ортогонально наличию дефолта.

Ну хватит нести чушь, ну прекращайте уже!

А если открыть сценарий NSIS…

Я не знаю, что такое NSIS, но ebuild элементарно читается как связный скрипт любым человеком с минимальными навыками программирования. А как DSL виде мейк-портянки с кучей dh-заклинаний разбирать… Я 20 лет с мейк знаком, но просто даже глядя на этот пример, мне сразу хочется попросить деньги за такую работу. Это точно не из разряда «для души» и «сам захотел опакетить софт людям на пользу».

Загуглил NSIS. Это виндузятное что-то. Очередной прыжок в сторону.

Разработчик, который плохо знает make… (И который ещё и считает bash-скрипты значительно лучшим выбором…)

Да, давай о моих навыках программирования поговорим.

Сначала обсудим отсутствие экранирования символов в make.

Потом порождающий неявные ошибки синтаксис.

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

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

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

Бесполезный хлам:

clean:
        dh_testdir
        dh_testroot
        rm -rf build build-stamp
        dh_clean
  
install-prep:
        dh_testdir
        dh_testroot
        dh_prep
        dh_installdirs

# This single target is used to build all the packages, all at once, or
# one at a time. So keep in mind: any options passed to commands here will
# affect _all_ packages. Anything you want to only affect one package
# should be put in another target, such as the install target.
binary-common:
        # See 633312, http://wiki.debian.org/ReleaseGoals/LAFileRemoval
        sed -i "/dependency_libs/ s/'.*'/''/" `find debian/ -name '*.la'`
        dh_testdir
        dh_testroot
        dh_installchangelogs
        dh_installdocs
        dh_installexamples
        dh_installmenu
        dh_lintian
        dh_strip
        dh_link
        dh_compress
        dh_fixperms
        dh_makeshlibs
        dh_installdeb
        dh_shlibdeps
        dh_gencontrol
        dh_md5sums
        dh_builddeb
        
# Build architecture independant packages using the common target.
binary-indep: build install
         $(MAKE) -f debian/rules DH_OPTIONS=-i binary-common
        
# Build architecture dependant packages using the common target.
binary-arch: build install $(EXTRA_INSTALL)
        $(MAKE) -f debian/rules DH_OPTIONS=-s binary-common
        
# Any other binary targets build just one binary package at a time.
binary-%: build install
        make -f debian/rules binary-common DH_OPTIONS=-p$*

build-arch: build
build-indep: build

binary: binary-indep binary-arch
.PHONY: build build-arch build-indep clean binary-indep binary-arch binary-common binary install install-prep

Наличие нескольких компиляторов вообще ортогонально наличию дефолта.

Так мы две страницы темы не можем прояснить содержательную сторону дефолта. Он нужен чтобы что?

Загуглил NSIS. Это виндузятное что-то. Очередной прыжок в сторону.

Ага. Ваш. Ибо вы сначала привели сценарий сборки из Void, а как только я заикнулся об этом же сценарии, начали приводить в ответ уже ebuild из Gentoo. Я не успеваю за вашим «взагали по загалям», извините.

Потом порождающий неявные ошибки синтаксис.

Ну уж bash-лапша то намного лучше! Язык без типизации, без адекватной обработки ошибок (command || true, ага), с кучей подводных камней (забыл кавычки? фигурные скобки? x$var = xy? set -u? pipefail? subshell-ы в pipe-ах?)…

make защищать не буду, но bash ничуть не меньшее говно.

Бесполезный хлам:

Ну и привели пакет, использующий старую систему сборки вместо dh с overrides.

Наличие нескольких компиляторов вообще ортогонально наличию дефолта.

Так мы две страницы темы не можем прояснить содержательную сторону дефолта. Он нужен чтобы что?

Чтобы команда c99 работала. Неужели всё ещё непонятно?

Ну уж bash-лапша то намного лучше!

Всё, что нужно от скрипта сборки, это две вещи.

Объявить десяток переменных такие как название пакета, версия, откуда качать, какие чексуммы и т.п.

И иметь возможность объявить функции для prepare(), build() и package(). В случае source-based дистрибутива там еще USE-флаги нужно учесть. Всё.

bash не лучшее, что изобрела цивилизация, но этот язык:

• Всё равно знают все разработчики под linux.
• Достаточен, чтобы справиться с вышеуказанным.

Какой-нибудь лисп, как в nixos, подошел бы, конечно, намного лучше. С абстрактных позиций. А с практических позиций bash позволяет снизить порог вхождения и привлечь больше энтузиастов.

Как этой задаче помогает портянка на make с кучей внутренних потрохов сборочной автоматики, вытащенных наружу, мне непонятно.

Я не успеваю за вашим «взагали по загалям», извините.

Могу еще вот такой пример привести: https://git.alpinelinux.org/aports/tree/main/gmp/APKBUILD

Arch, Void, Gentoo, Alpine — это всё примеры дистрибутивов с качественной сборочной автоматикой, где труд мейнтейнера пакета сосредоточен на решении фактических сборочных задач, а не на борьбе с бесполезным низкоуровневым DSL.

Ну и привели пакет, использующий старую систему сборки вместо dh с overrides.

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

Чтобы команда c99 работала. Неужели всё ещё непонятно?

Допустим, она работает:

$ pacman -Qo c99
/usr/bin/c99 принадлежит gcc 11.1.0-1

Какой-нибудь лисп, как в nixos

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

Допустим, она работает:

Ясно. Хотите дальше прикидываться шлангом «я не понимаю, о чём речь» — ради бога. До побачення.

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

Блин, точно.

Ну то есть больше сказать нечего.

Покажи новую.

Ах да, забыл.

Пройдите к исходному сообщению, там есть ссылка.

А с разбиением на множественные пакеты?

Ну то есть больше сказать нечего.

Естественно. Кто хотел, уже всё понял.

Вы показали принадлежность /usr/bin/c99 конкретной реализации в то время как всё это время речь шла о возможности переключения между реализациями — если вы считаете, что всё написали правильно, то с вами просто не о чем разговаривать.

ЗАЧЕМ нужно переключение реализации.

А с разбиением на множественные пакеты?

https://sources.debian.org/src/nautilus/41.1-1/debian/rules/

Это вообще не задача debian/rules. Какие файлы отправляются в какие пакеты, зависит от содержимого debian/pkgname.install.

Это вообще не задача debian/rules.

Раньше была задача:

install: build-stamp install-prep
        rm -rf debian/tmp
        # Install places gmp.h in 'includeexecdir' which is non-standard and cannot be set at compile time,
        # so override it at install.
        $(MAKE) DESTDIR=`pwd`/debian/tmp includeexecdir=/usr/include/$(DEB_HOST_MULTIARCH) -C build install

        dh_install -plibgmp10 usr/lib/*/libgmp.so.*
        dh_install -plibgmpxx4ldbl usr/lib/*/libgmpxx.so.*

        dh_install -plibgmp-dev usr/lib/*/lib*.so
        dh_install -plibgmp-dev usr/lib/*/lib*.a
        dh_install -plibgmp-dev usr/lib/*/pkgconfig
        dh_install -plibgmp-dev usr/include

        # Install upstream ChangeLog, AUTHORS, NEWS, and README only in -dev package
        dh_installchangelogs -plibgmp-dev
        dh_installdocs -plibgmp-dev AUTHORS NEWS README

ЗАЧЕМ нужно переключение реализации.

Затем, чтобы общесистемно использовать другую реализацию. Например, чтобы c99 по умолчанию предоставлялся clang, а значит, при сборке и вызове /usr/bin/c99 использовался clang. Потому что я хочу по умолчанию clang как имплементацию /usr/bin/c99.

Что тут вообще можно не понимать?

Ты понимаешь, что c99 означает «КАКОЙ-ТО компилятор C99»?

Вот в системе КАКОЙ-ТО и стоит. Всё равно какой. А КАКИМ-ТО компилятором только хеллоу ворлды и тестовые задания можно компилять.

А в жизни тебе всё равно нужен gcc, clang, icc и т.п.

И не просто какой-нибудь, а, скажем, строго gcc 8-й версии.

Или кросскомпилятор с кастомными патчами.

Переключать c99 на строго на gcc 11 и завязывать всю свою сборочную систему на то, что по команде c99 всегда запускается gcc 11 — всё равно что симлинкать /bin/sh на bash и вызывать баш-скрипты через /bin/sh.

Это нарушение соглашений о именовании.

Это СОЗДАЁТ конфликты имён, а не РЕШАЕТ их.

Ты понимаешь, что c99 означает «КАКОЙ-ТО компилятор C99»?

Да, блин, понимаю. И если я собираю тулзу, которая вызывает /usr/bin/c99, то я хочу, чтобы этим c99 был clang.

А КАКИМ-ТО компилятором только хеллоу ворлды и тестовые задания можно компилять.

Ну что за бред…

И если я собираю тулзу, которая вызывает /usr/bin/c99, то я хочу, чтобы этим c99 был clang.

Лицорука.

Ну в принципе понятно. А sh - это bash. А make - это gmake.

Переключать c99 на строго на gcc 11 и завязывать всю свою сборочную систему на то, что по команде c99 всегда запускается gcc 11

Сам придумал — сам опроверг.

Может, вы и дальше сами с собой разговаривать будете? А то пользы от разговора с вами ноль, а значит, я лишь зря теряю своё время.

Ну что за бред…

Путать интерфейс и реализацию - действительно бред. А вроде рассуждаешь как разработчик, в сборке пакетов под дебиан разбираешься.

А в голове каша.

Сам придумал — сам опроверг. Может, вы и дальше сами с собой разговаривать будете? А то пользы от разговора с вами ноль, а значит, я лишь зря теряю своё время.

Снова нечего возразить с позиции разработчика, снова пошел в разнос =)

Снова нечего возразить с позиции разработчика

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

Вы сами придумали, что я якобы хочу завязаться на конкретную реализацию

И если я собираю тулзу, которая вызывает /usr/bin/c99, то я хочу, чтобы этим c99 был clang.

И этот тупняк мне приходится читать… Кошмар.

А вам не приходило в голову, что если выбирается clang как реализация c99, то это, блин, не означает, что я завязываюсь на clang в коде? Может, он оптимизирует лучше, или собирает быстрее, или ошибки более понятные выдаёт? Нет, не приходило? — оно и видно.

Я ж говорю: «сам придумал — сам опроверг».

Вызывать clang как clang запрещает какое-то верование или что?

Каким образом выбор из равноценных реализаций означает завязывание на эту реализацию? Ну что за дикий бред вы несёте?

Имеем интерфейс И и его реализации Р1 и Р2. Если я использую Р2 через И, то я завязываюсь на интерфейс И, а не конкретную реализацию Р2. Так понятнее?

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

Честное слово, надоело уже. Будем считать, что это я так плохо объясняю, что вы никак не можете понять.

Вызывать clang как clang запрещает какое-то верование или что?

BTW, вот это и есть завязывание на конкретную реализацию.

Ну и? Вот в Арче решили gcc всунуть как «an interface to the standard C compilation system». Всё логично.

Но вы почему-то непременно хотите переопределять стандартные утилиты симлинками. Будто это ваше святое право ;)

А почему бы не переопределить ls, rm или ping? Как там дебиан предусматривает такую возможность из коробки? Или придётся снести coreutils и iputils?

Это было первое.

Теперь второе. Там в документе написано: c99. А не /usr/bin/c99.

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

BTW, вот это и есть завязывание на конкретную реализацию.

Если мне нужен clang, я вызываю clang.

Если мне нужен (всё равно какой, лишь бы POSIX-совместимый) sed, я вызываю sed.

Если мне нужен конкретно gawk, я вызываю gawk.

Это называется использовать имена по их смыслу, и не пытаться втиснуть в имена то, что они не означают.

Вот в Арче решили gcc всунуть как «an interface to the standard C compilation system».

Ну вот в Debian можно стандартным способом выбрать реализацию, предоставляющую /usr/bin/c99, а в Arch нет. Вам лично это, возможно, не нужно — но вы лично это ещё не все люди мира.

Теперь второе. Там в документе написано: c99. А не /usr/bin/c99.

Обсуждается Debian, в котором данная команда расположена по данному пути.

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

Если мне нужен clang, я вызываю clang.

Если мне нужен (всё равно какой, лишь бы POSIX-совместимый) sed, я вызываю sed.

А если нужен C99-компилятор (всё равно какой, в рамках описанного интерфейса), то в правилах сборки по дефолту указываю c99.

Это называется использовать имена по их смыслу, и не пытаться втиснуть в имена то, что они не означают.

Что означает c99, чётко определено — см. стандарт. Использование c99 как компилятора C99 не противоречит предназначению c99 от слова «никак».

В Debian есть несколько реализаций c99. Debian позволяет стандартным способом выбрать реализацию c99. В чём проблема - в упор не вижу.

Продолжение разговора считаю бессмысленным. Можете ещё раз написать, что мне-де просто нечего сказать.

Осталось войд попробывать.

Просто во время установки пакета выводит на экран все его опциональные зависимости.

Блин, точно. Войд же стоял на ноуте, который я оставил бывшей.

Ну то есть основной функционал заменяем на работу вручную и называем это более быстрой заменой. Гениально.

основной функционал

Это что за зверь?

Я обдумал диалог и все кейсы, которые в нём обсуждались.

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

Но стремление дебиана что угодно объявить альтернативой, как то pager или editor, не одобряю.

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

Гениально.

Конечно гениально.

Мне ни разу за время использование дебиана не сослужили добрую службу ни suggested packages, ни даже recommended packages. Всегда эту бесполезную опцию приходилось отключать.

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

И за 10 лет мне автоматическая установка рекомендаций никогда не пригодилась.

Кстати, а есть какой-то итоговый индекс, где перечислены все пакеты из состава релиза, объявляющие альтернативы?

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

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

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

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

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

При том, что речь в этой ветке диалога шла про рекомендованные пакеты, а не про зависимости.

Кстати вот так pacman удобно отображает рекомендации:

Ставим какой-нибудь пакет:

# pacman -S kate
разрешение зависимостей...
проверка конфликтов...

Пакет (37)                 Новая версия  Изменение размера  Размер загрузки

extra/attica               5.88.0-1               1,39 MiB         0,54 MiB
extra/editorconfig-core-c  0.12.5-1               0,10 MiB         0,03 MiB
extra/http-parser          2.9.4-1                0,06 MiB         0,02 MiB
extra/kactivities          5.88.0-1               0,87 MiB         0,32 MiB
extra/karchive             5.88.0-1               0,75 MiB         0,37 MiB
extra/kauth                5.88.0-1               0,94 MiB         0,32 MiB
extra/kbookmarks           5.88.0-1               1,30 MiB         0,59 MiB
extra/kcodecs              5.88.0-1               1,15 MiB         0,36 MiB
extra/kcompletion          5.88.0-1               1,62 MiB         0,70 MiB
extra/kconfig              5.88.0-1               3,38 MiB         1,11 MiB
extra/kconfigwidgets       5.88.0-1               3,31 MiB         1,22 MiB
extra/kcrash               5.88.0-1               0,32 MiB         0,12 MiB
extra/kdbusaddons          5.88.0-1               0,64 MiB         0,24 MiB
extra/kded                 5.88.0-1               0,11 MiB         0,05 MiB
extra/kglobalaccel         5.88.0-1               0,65 MiB         0,24 MiB
extra/kguiaddons           5.88.0-1               0,76 MiB         0,31 MiB
extra/ki18n                5.88.0-1              17,69 MiB         1,94 MiB
extra/kiconthemes          5.88.0-1               1,03 MiB         0,51 MiB
extra/kio                  5.88.0-1              26,86 MiB         7,75 MiB
extra/kitemviews           5.88.0-1               1,50 MiB         0,60 MiB
extra/kjobwidgets          5.88.0-1               1,04 MiB         0,35 MiB
extra/knewstuff            5.88.0-1               5,60 MiB         1,91 MiB
extra/knotifications       5.88.0-1               1,06 MiB         0,48 MiB
extra/kpackage             5.88.0-1               1,04 MiB         0,33 MiB
extra/kparts               5.88.0-1               2,37 MiB         1,02 MiB
extra/kservice             5.88.0-1               1,88 MiB         0,72 MiB
extra/ktexteditor          5.88.0-1              13,98 MiB         3,53 MiB
extra/ktextwidgets         5.88.0-1               2,20 MiB         0,85 MiB
extra/kuserfeedback        1.0.0-1                2,54 MiB         0,47 MiB
extra/kwallet              5.88.0-1               2,16 MiB         0,51 MiB
extra/kxmlgui              5.88.0-1               4,74 MiB         1,69 MiB
extra/libgit2              1:1.2.0-1              1,84 MiB         0,60 MiB
extra/qt5-speech           5.15.2-1               0,17 MiB         0,05 MiB
extra/sonnet               5.88.0-1               2,34 MiB         0,65 MiB
extra/syndication          5.88.0-1               2,39 MiB         1,00 MiB
extra/syntax-highlighting  5.88.0-1               9,16 MiB         1,36 MiB
extra/kate                 21.08.3-1             24,38 MiB         8,14 MiB

Будет загружено:     41,02 MiB
Будет установлено:  143,33 MiB

:: Приступить к установке? [Y/n] 
:: Получение пакетов...

И в конце установки видим все рекомендации, и для чего каждая может потребоваться:

:: Обработка изменений пакета...
( 1/37) установка kjobwidgets
Дополнительные зависимости для 'kjobwidgets'
    python-pyqt5: for the Python bindings [установлено]
( 2/37) установка kdbusaddons
Дополнительные зависимости для 'kdbusaddons'
    python-pyqt5: for the Python bindings [установлено]
( 3/37) установка kconfig
Дополнительные зависимости для 'kconfig'
    python-pyqt5: for the Python bindings [установлено]
( 4/37) установка kcrash
Дополнительные зависимости для 'kcrash'
    drkonqi: KDE crash handler application
( 5/37) установка kglobalaccel
( 6/37) установка kauth
Дополнительные зависимости для 'kauth'
    python-pyqt5: for the Python bindings [установлено]
( 7/37) установка kcodecs
Дополнительные зависимости для 'kcodecs'
    python-pyqt5: for the Python bindings [установлено]
( 8/37) установка kguiaddons
Дополнительные зависимости для 'kguiaddons'
    python-pyqt5: for the Python bindings [установлено]
( 9/37) установка ki18n
Дополнительные зависимости для 'ki18n'
    python-pyqt5: for the Python bindings [установлено]
    python: to compile .ts files [установлено]
(10/37) установка kconfigwidgets
Дополнительные зависимости для 'kconfigwidgets'
    python-pyqt5: for the Python bindings [установлено]
    perl: for preparetips5 [установлено]
(11/37) установка kitemviews
Дополнительные зависимости для 'kitemviews'
    python-pyqt5: for the Python bindings [установлено]
(12/37) установка karchive
(13/37) установка kiconthemes
Дополнительные зависимости для 'kiconthemes'
    breeze-icons: fallback icon theme
(14/37) установка kxmlgui
(15/37) установка kbookmarks
(16/37) установка qt5-speech
Дополнительные зависимости для 'qt5-speech'
    flite: flite TTS backend
    speech-dispatcher: speech-dispatcher TTS backend [установлено]
(17/37) установка knotifications
Дополнительные зависимости для 'knotifications'
    qt5-declarative: QML bindings [установлено]
(18/37) установка kservice
(19/37) установка kwallet
Дополнительные зависимости для 'kwallet'
    kwalletmanager: Configuration GUI
(20/37) установка kcompletion
Дополнительные зависимости для 'kcompletion'
    python-pyqt5: for the Python bindings [установлено]
(21/37) установка sonnet
Дополнительные зависимости для 'sonnet'
    hunspell: spell checking via hunspell [установлено]
    aspell: spell checking via aspell [установлено]
    hspell: spell checking for Hebrew [установлено]
    libvoikko: Finnish support via Voikko [установлено]
    qt5-declarative: QML bindings [установлено]
(22/37) установка ktextwidgets
(23/37) установка kded
(24/37) установка kio
Дополнительные зависимости для 'kio'
    kio-extras: extra protocols support (sftp, fish and more)
    kdoctools: for the help kioslave
    kio-fuse: to mount remote filesystems via FUSE
(25/37) установка kpackage
(26/37) установка attica
(27/37) установка syndication
(28/37) установка knewstuff
Дополнительные зависимости для 'knewstuff'
    kirigami2: QML components
(29/37) установка kparts
(30/37) установка syntax-highlighting
Дополнительные зависимости для 'syntax-highlighting'
    qt5-declarative: QML bindings [установлено]
(31/37) установка http-parser
(32/37) установка libgit2
(33/37) установка editorconfig-core-c
(34/37) установка ktexteditor
(35/37) установка kactivities
Дополнительные зависимости для 'kactivities'
    qt5-declarative: QML bindings [установлено]
(36/37) установка kuserfeedback
Дополнительные зависимости для 'kuserfeedback'
    qt5-declarative: QML bindings [установлено]
    qt5-charts: User Feedback console
    qt5-svg: User Feedback console [установлено]
(37/37) установка kate
Дополнительные зависимости для 'kate'
    konsole: open a terminal in Kate
    clang: C and C++ LSP support [установлено]
    python-lsp-server: Python LSP support
    texlab: LaTeX LSP support
    rust: Rust LSP support
    git: git-blame plugin [установлено]
:: Запуск post-transaction hooks...
(1/4) Arming ConditionNeedsUpdate...
(2/4) Reloading system bus configuration...
(3/4) Updating icon theme caches...
(4/4) Updating the desktop file MIME type cache...

Не помню, умеет ли так APT.