Ubuntu 23.04

Ну тут согласен, ключи пакмана куда очевиднее. Единственное что ключ -c может устроить сюрприз, для острых ощущений можно ещё и –noconfirm добавить

Единственное что ключ -c может устроить сюрприз

Это очень удобно. Вбиваешь какую-нибудь зависимость снизу и сносишь сразу всё на ней растущее. Ну или просто смотришь зависимости таким образом.

https://wiki.archlinux.org/title/Pacman/Rosetta

Как минимум в части apt устарело.

Install package(s) as dependency / without marking as explicitly required.

apt-mark auto

Правильный вариант: apt install --mark-auto ...

Show a log of actions taken by the software management.

read /var/log/dpkg.log

Наверное, всё же /var/log/apt/history.log?

Show all or most information about a package. The tools’ verbosity for the default command vary. But with options, the tools are on par with each other.

apt show or apt-cache policy

Нафига так писать? apt show ... или apt policy ....

Display local package information: Name, version, description, etc.

dpkg -s or aptitude show

WTF? apt show ...

Display remote package information: Name, version, description, etc.

apt-cache show or aptitude show

apt show ...

Show the changelog of a package

apt-get changelog

apt changelog ...

Display a list of all packages in all installation sources that are handled by the packages management. Some tools provide options or additional commands to limit the output to a specific installation source.

apt-cache dumpavail or apt-cache dump (Cache only) or apt-cache pkgnames

apt list

Generates a list of installed packages

dpkg –list | grep ^i

apt list --installed

List packages that are installed but are not available in any installation source (anymore).

apt –installed list | grep ,local

apt list ~o (использует шаблоны поиска – кстати, что-то подобное в pacman есть?)

List packages not required by any other package

deborphan -anp1

apt list ~g

List packages installed explicitly (not as dependencies)

apt-mark showmanual

apt list '~i!~M'

List packages installed automatically (as dependencies)

apt-mark showauto

apt list ~M

Display packages which require X to be installed, aka show reverse dependencies.

apt-cache rdepends or aptitude search ~D$pattern

apt rdepends ...

Display packages which conflict with given expression (often package). Search can be used as well to mimic this function.

aptitude search ‘~C$pattern’

apt list '~DConflicts:...'

List all packages which are required for the given package, aka show dependencies.

apt-cache depends or apt-cache show

apt depends ...

List all packages that require a particular package

aptitude search ~D{depends,recommends,suggests}:$pattern or aptitude why or apt-cache rdepends

apt rdepends --installed ...

Display all packages that the specified packages obsoletes.

apt-cache show

apt list '~DObsoletes:...'

Refresh the information about the specified installation source(s) or all installation sources.

apt-get update

apt update

Prints a list of all installation sources including important information like URI, alias etc.

apt-cache policy

apt policy

List all packages from a certain repo

(ничего не указано)

apt list ~A... или apt list '?codename(...)' или apt list ~O... (по разным критериям: архив, имя выпуска, происхождение).

Download packages from a different version of the distribution than the one installed.

apt-get install -t release package or apt-get install package/release (dependencies not covered)

s/apt-get/apt/g

Install/Remove packages to satisfy build-dependencies. Uses information in the source package

apt-get build-dep

Same.

Display the source package to the given package name(s)

apt-cache showsrc

apt showsrc ...

Download the corresponding source package(s) to the given package name(s)

apt-get source

apt source ...

Шаблоны поиска, кстати, офигенная штука. Мало того что они позволяют строить сложные выражения выборки, так ещё и над ними можно производить действия (пример: apt purge ~o), и даже устанавливать приоритеты в apt/preferences.

Шаблоны поиска и в пакмане есть. Только вот аргументы пакетного менеджера там не такие упоротые.

Ты это прям сейчас придумал

Конечно, всегда так делаю.

чем пользуетесь?

Дебианом же. Вернее теперь уже альтом, но хрен редьки не сильно слаще.

Ну так поведай, как вызвать конфликт apt и aptitude

Вот, прекрасная иллюстрация насколько утилита apt удобнее того треша, что был раньше. А чо, сразу так нельзя было?

Наставить hold в аптитуде, а потом обновиться апт-гетом.

Шаблоны поиска и в пакмане есть

Пруф? А то в https://wiki.archlinux.org/title/pacman и https://wiki.archlinux.org/title/pacman/Tips_and_tricks только такое:

# pacman -S $(pacman -Ssq package_regex)

да такое:

$ LC_ALL=C pacman -Si packages | awk -F'[:<=>]' '/^Depends/ {print $2}' | xargs -n1 | sort -u

В apt же это:

apt install ~nregex

apt list '~RDepends:(~nregex1|~nregex2|...)'

Можно даже обновить одной командой все установленные вручную пакеты архитектуры i386, которые зависят от пакетов, собираемых из исходного кода проектов, начинающихся на «xorg»:

# Краткий синтаксис
apt install '~U !~M ~ri386 ~D~e^xorg'
# Полный синтаксис для читабельности, например в скриптах
apt install '?upgradable ?not(?automatic) ?architecture(i386) ?depends(?source-package(^xorg))'

Я такое только в aptitude видел (откуда они в apt и пришли), да в FreeBSD-шном pkg что-то подобное есть.

Только вот аргументы пакетного менеджера там не такие упоротые

Вы сейчас точно про pacman? XD

Вы сейчас точно про pacman? XD

https://archlinux.org/pacman/pacman.8.html На, читай.

У всего есть длинные ключи с адекватными названиями.

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

-Rscn, например, это - --remove --recursive --cascade --nosave. Логично? Логично.

Что за бред ты несешь? apt install ./package.deb — ставит локальный пакет и качает зависимости.

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

-Rscn, например, это - –remove –recursive –cascade –nosave. Логично? Логично.

-s – это --recursive? В других утилитах именно такая запись для рекурсии используется, да. Очень логично звучит. И -S для установки – тоже логично. Совсем не «search» первым в голову приходит. /s

Да и требовать для таких частых операций как установка/обновление/удаление пакетов ключи в верхнем регистре – это особый подход к эргономике.

А вообще, раз уж пошла такая пьянка, то вот есть в Debian такой пакет как apt-listbugs. Этот пакет интегрируется в apt, выводя информацию о серьёзных багах в устанавливаемых/обновляемых пакетах из багтрекера Debian.

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

Причём apt-listbugs предлагает пользователю возможность избежать («dodge») определённые баги: такие пакеты фиксируются на текущей версии и поэтому не будут обновлены на версию с багом; более того, как только данный баг будет закрыт и исправленная версия будет залита в репозиторий, фиксация автоматически снимается, снова позволяя обновить этот пакет!

Эта утилита позволяет без напряга избежать этак 90% серьёзных проблем при использовании unstable-ветки Debian.

Есть ли что-то подобное в Arch для pacman?

Если удалить ядро или повредить initramfs, то да, загрузка сломается.

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

Ну как-то мой мозг проще запоминает pacman -Rscn, чем apt autoremove –purge

Признаю, я слишком тупой для апта.

Не для апта, а в целом.

apt install ./package.deb — ставит локальный пакет и качает зависимости.

sudo nala install ./*.deb тоже отлично справлятся, как я узнал благодаря комментам в этой новости :)

В арче ядро одно, что является большим плюсом. Например если загружаться через EFISTUB. Ну их может быть и несколько, linux-rt, linux-hardened. А версий ядра нет, оно одно. Файл называется просто vmlinuz-linux, без версии.

без проблем запоминаешь сразу короткие

Нет

Нет. Арч преимущественно пакетирует апстрим as is с минимальным тестированием в ветке testing. Исключение обычно составляют важные системные компоненты, куда могут включаться фиксы критичных багов.

В общем, роллинг не для тех, кому нужен отдельный надзиратель, защищающий юзера от багов апстрима :D

Да и требовать для таких частых операций как установка/обновление/удаление пакетов ключи в верхнем регистре – это особый подход к эргономике.

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

Я ж говорю, я слишком тупой, я не осилил систему команд апта.

-s – это –recursive? В других утилитах именно такая запись для рекурсии используется, да. Очень логично звучит. И -S для установки – тоже логично. Совсем не «search» первым в голову приходит. /s

search - это -s там, где это имеет смысл. search выполняется в одной из двух БД - или по БД установленных пакетов или по репозиторию. Соответственно это будут -Qs и -Ss.

В команде удаления поиск не нужен.

И -S для установки – тоже логично. Совсем не «search» первым в голову приходит. /s

Sync же. Так прямо в мане и написано.

apt install ./package.deb — ставит локальный пакет и качает зависимости

Я же написал, что работает с бубном. Теперь интересно, откуда вы узнали этот хак с указанием пути? В мане про это молчок. Из книжки «Секреты и советы дебилиана»?

То, что зависимости не указывают точную версию so, был бы недостаток для сервера. А для домашней машины это скорее упрощение.

Ребят, вы так прикалываетесь?

Как раз на сервере (где нынче вообще примерно всё в контейнерах на альпайне) особой надобности в умных пакетных менеджерах (уже) нет.

Да и когда/если не было контейнеров — количество апдейтов софта на сервере кратно (в разы, на порядки) меньше количества апдейтов на рабочей станции: каждый сервер выполняет ограниченное число задач (в идеале: одну), и держать разнообразный софт на нём попросту не нужно.

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

А пакман не бьёт.

Рассмотрим тривиальный пример на базовом софте. К примеру, утилита file.

Видим там такое:

depends=('glibc' 'zlib' 'xz' 'bzip2' 'libseccomp' 'libseccomp.so' 'zstd' 'libzstd.so')

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

Зависит от : glibc zlib xz bzip2 libseccomp libseccomp.so=2-64 zstd libzstd.so=1-64

Нет, не добавилось, только к зависимостям вида libxxx.so пробилась, хвала инженерам, мажорная версия библиотеки.

Что это значит в практическом плане? Например, что пакет bzip2 можно апдейтить вообще как угодно, не заботясь о зависящих от него программ. Между тем, этот самый file жёстко зависит от libbz2.so.1.0:

> ldd /bin/file  
        linux-vdso.so.1 (0x00007ffcd93d3000)
        libmagic.so.1 => /usr/lib/libmagic.so.1 (0x00007fe7c3bae000)
        libseccomp.so.2 => /usr/lib/libseccomp.so.2 (0x00007fe7c3b8e000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fe7c39a7000)
        libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007fe7c38d7000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007fe7c38a4000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007fe7c3891000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fe7c3875000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe7c3c13000)

И если при апдейте у libbz2 поменяется SONAME, то file окажется сломан. А paсman при этом даже не дёрнется, с его точки зрения всё нормально.

Конечно, у libbz2 редко меняется SONAME, и вероятность такой поломки невелика. Но вот у библиотек из комплекта ffmpeg, всех этих libav* SONAME’ы меняются постоянно. И куча софта (навскидку: telegram-desktop, qt5-webengine, chromium, simplescreenrecorder…) в манжаро (и, подозреваю, в арче — те же пакеты) зависит от ffmpeg, а не от libavcodec.so=60-64 . Соответственно, сто́ит мне собрать пакет с обновлённым ffmpeg-ом, поставить его в систему строго через пакетный менеджер — и хоба-на, с точки зрения пакетного менеджера всё хорошо, а вот запускаться программы перестали.

И это, замечу, мы ещё не перешли к ситуациям, когда интерфейс библиотеки меняется без смены SONAME. Тут, к слову, не каждый RPM справится (хотя, например, альтовый справлялся).

В общем, pacman — это такой велосипед для тех, кто любит педалить. Не скрою: у самого сейчас на локалхостах остался только Arch, точнее, его производные: Manjaro на рабочих станциях и ArchArm на RPi4b. Он похож на тот прикольный конструктор, которым линукс был, когда меня на него подсадили почти больше четверти века назад, только задокументирован гораздо-гораздо лучше.

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

Ребят, вы так прикалываетесь?

Нет.

Как раз на сервере (где нынче вообще примерно всё в контейнерах на альпайне) особой надобности в умных пакетных менеджерах (уже) нет.

На сервере, если я что-то поставил, оно expected to work. Вчера, сегодня и послезавтра, после любых апдейтов.

На локалхосте если что-то сломалось, но починю, руки не отвалятся.

А пакман не бьёт.

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

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

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

Да. Он прикольнее, чем «серьёзные» системы.

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

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

В общем, pacman — это такой велосипед для тех, кто любит педалить.

Опять ты путаешь ПМ и политику пакетирования дистрибутива. Пакману, как и апту, пофиг на реальный смысл указанных зависимостей. Что указали, с тем и работает.

В общем, s/pacman/Arch/

Окей, в мане и правда нет. Но первый же запрос в поиск выдает этот ответ.

А это, кстати, упущение. Записал себе в TODO.

Нет, конечно же.

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

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

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

Если же ты про то, что пакман воспринимает эти зависимости как строчки, в лучшем случае, строчки с указанием версии и предиката — ну и что? DSL такой. Другое дело, что в пакмановской сборочной машинерии нет, например, такой операции как запуск ldd на бинарники и анализаторов включенных модулей, например, на питоновские скрипты. От этого в зависимостях оказывается только то, что явно прописано, и для сложных проектов с миллиардом звоночков и свисточков (например, homeassistant) оно оказывается малополезным, проще уж pip-ом ставить.

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

Главное чтобы emerge не получился. Это ж надо было сделать НАСТОЛЬКО медленный пакетный менеджер, даже без учёта компиляции.

Ты слишком много хочешь от слаки на стероидах. И главное, слаке на стероидах это совершенно не надо. Её не за это выбирают.

Патамушта не Canoniчно :) Типа победа бизнеса над свободой выбора. Может оно и нахрен не надо, но snap, типа, свой, а чужих не пустим. Вот firefox уже в 22.04 LTS только в снапе поставляется, а если хочешь из репы тянуть, то делай приседания. Хотят, видимо, много чего в снапах поставлять и flatpack им целостность мира рушит.

Полагаю, что пока нет. И это «пока» может сильно затянуться.

Когда дошло до создания пользователя, нельзя переключиться на английский, а на кириллице нельзя создать пользователя.

раскладки не было в настройках eng, только одна ru но настройки ОС доступны ! (в рамках инсталятора) добавил eng и смог переключится )

Rootlexx

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

Всё можно - делайте: есть же уже debian testing. Было бы глупо делать еще один debian с другим названием.

Я уже объяснял ни один раз, почему по совокупности характеристик мне удобнее арч на десктопе.

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

Так речь и не о вас.

Чой-та? Моя имха против другой имхи. Всё честно.

Ах да, ключи, меняющие своё значение в зависимости от контекста, — это тоже особый подход к UX.

Нормальный подход. Было бы странно, если бы у cp и ls ключи были одинаковые.

Нет смысла обсуждать очевидное — кому надо, уже и так всё понял

«Одна я в белом платье стою красивая».

Ok, договорились.

С тезисом «Патрег — бох» я спорить не готов.

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

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

В арче ядро одно

Даже не удивлён - если уж рач недоделка, то по всем фронтам.

На фоне того, что я за 10 лет не смог вызубрить ключи апта

Это не удивляет как раз. Странно что ты шнурки завязывать научился с такими невероятными интеллектуальными способностями.

Я ж говорю, я слишком тупой

Не, не слишком - обычный занудный обыватель.

Если уж говорить про недостатки dpkg, до давайте вспомним про

dpkg: ошибка при обработке пакета package (--configure): 
подпроцесс из пакета package 
установлен сценарий post-installation возвратил код ошибки 1 
При обработке следующих пакетов произошли ошибки: 
package 
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

А разделение на dpkg и apt — это странная претензия.

А какой тут может быть более информативный вывод?

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

Позволю себе Вам напомнить, что «дамы мушку наносили», исключительно для того, чтоб дать понять кавалерам (всяким Ржевским в особенности) о собственной доступности :) Так что в контексте арча и пакмена - это, в принципе, прекрасное сравнение.

Одобрямс :)

Не хотелось продолжать эту ветку, но раз уж вы подглядываете в удалённые…

Всё можно - делайте: есть же уже debian testing. Было бы глупо делать еще один debian с другим названием.

А можно аргументированное обоснование, почему такая утилита/функциональность не нужна в Arch? — Чтобы не быть как Debian? Или потому что пользователь Arch должен страдать по определению?

В чём вообще смысл того чтобы вместо простого «Да, было бы неплохо, но такого пока нет» — классически пытаться доказать, что «ненужно!11»?

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

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

Нормальный подход. Было бы странно, если бы у cp и ls ключи были одинаковые.

cp и ls — это разные программы, в то время как в случае pacman речь идёт о ключах, меняющих своё поведение в рамках одной программы.

Искренне ваш, К.О.

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

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

Но вот с тем, что dpkg есть куда улучшать, я согласен полностью.

Мигрировал на 23.04 с 20.04, если кратко - оно того не стоит. Ничего нового и интересного не получил. Лучше не стало, хотя и практически хуже тоже не стало.

• Как были проблемы с подключением bluetooth гарнитуры, так они и остались. AAC кодека как не было так и нет (типа из-за патентов? Rly?).
• Как не выключалась без хакинга дискретка жрущая батарею, так и не выключается.
• Мелкие глюки, как пример: если запущены clocks (часы и таймеры) и одновременно калькулятор, то при взаимодействии с калькулятором появляется сообщение «clocks не отвечает. Подождать/Закрыть ?», если закрыть калькулятор то clocks опять работает.
• Инсталятор порезали, теперь нет возможности создать шифрованный раздела (Luks), пришлось его создавать уже после инсталляции.

Из позитивного: теперь мой ноут на Ryzen 5 3550H наконец не требует для нормального старта использовать параметр ядра iommu=soft, видно в ядре 6.2 пофорсили какие-то проблемы с Zen+.

Людей которые отказались от Ubuntu в пользу Fedora я теперь могу понять.

Не хотелось продолжать эту ветку, но раз уж вы подглядываете в удалённые…

Я вообще писал ответ, когда удалённое было неудалённым)

А можно аргументированное обоснование, почему такая утилита/функциональность не нужна в Arch? — Чтобы не быть как Debian? Или потому что пользователь Arch должен страдать по определению? В чём вообще смысл того чтобы вместо простого «Да, было бы неплохо, но такого пока нет» — классически пытаться доказать, что «ненужно!11»?

«Было бы неплохо, но пока нет» - это, например, из ~390 install-скриптов выкинуть большую часть, заменив на декларативные способы. Там половина тупо выводит сообщение в терминал, а из оставшихся еще около половины легко превращается в хуки.

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

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

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

cp и ls — это разные программы, в то время как в случае pacman речь идёт о ключах, меняющих своё поведение в рамках одной программы.

Ну возьмём busybox, там это одна программа. Вы упускаете суть, cp и ls - разные команды, точно так же как и pacman --sync и pacman --query - разные команды.

В git checkout и git tag опция -d означает разные вещи. Ну и что?

из ~390 install-скриптов выкинуть большую часть, заменив на декларативные способы

Это, кстати, полностью поддерживаю.

А указанная фича, она конкретно в Арче не нужна по причине того, что partial updates официально не поддерживаются.

Тем не менее, возможность фиксации пакета официально присутствует в самом pacman и даже описывается на основной Wiki-странице, посвящённой pacman. Раз уж так, то дать такую возможность пользователям, которые понимают и принимают все связанные риски, на мой взгляд, было бы неплохо. Тем более что для rolling такая возможность наиболее актуальна.

Вы упускаете суть, cp и ls - разные команды, точно так же как и pacman –sync и pacman –query - разные команды.

В git checkout и git tag опция -d означает разные вещи. Ну и что?

Тут можно спорить, ибо в случае pacman это ключи, а в случае git — субкоманды. Но я вашу позицию понял.

тем временем узкозаточенный update-alternatives прямо в репах арча. Официальный

При том, что штука довольно удобная - пока на работе была 8, я петпрожекты под 15-17 пилил, переключаться туда-сюда - для пакетов она таки бессмысленна - согласно рекомендациям нельзя дергать ее туда сюда при запуске, она раньше даже не была в зависимостях к жава приложениям (кажется?), а нужно пилить свой sh файл, в котором оверрайдишь PATH, типа такого:

https://aur.archlinux.org/cgit/aur.git/tree/pdfsam?h=pdfsam

пруфов не дам, возможно, это было в личной беседе

При этом сам debian/ за каким-то хером вкладывается в каталог-исходник программы, и всё это вместе так и лежит у них в дереве сорцов

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

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

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

inb4, работает он, правда, с перебоями, пачку false-positive часто выдает, особенно, на упомянутом питоне, где зависимости вполне себе опциональные

Так я про вложенность, а не про сорцы.

Вот про вложенность папки debian в сорцы кстати вопрос возник.

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

А в дебиане как его скачать?