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

Универсальная система была бы, если бы там сразу создавался контейнер с полной виртуализацией содержимого /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

Минут 40

Это 40 минут калькуляция зависимостей? Калькулятор Феликс?

Сейчас проверил - синхронизация дерева portage 2 минуты, калькуляция зависимостей 30 сек.

Какой-нибудь лисп, как в 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 запрещает какое-то верование или что?