From: kmeaw
Date: 2021-09-21 20:48:37Z
Просто у разных людей разные цели.
Разработчик прикладной программы хочет, чтобы окружение, в котором
работает его программа у пользователя было похоже на его собственное
окружение, в котором он эту программу протестировал. И в этом есть свои
плюсы - например, получив сообщение об ошибке от пользователя, ему будет
сильно проще воспроизвести её у себя и со временем исправить причину её
возникновения.
Но есть и другая сторона - эксплутационная. Аргумент про OpenSSL
останется верным вне зависимости от того, используется статическая или
динамическая линковка, и дело не только в исправлении багов самой
OpenSSL путём обновления. Мейнтейнеры Debian проделывают большую работу,
накладывая патчи на кучу пакетов, чтобы сделать систему более целостной,
чтобы всё было не так, как хочет разработчик одной определённой
прикладной программы, а так, как принято в данной системе - это и
расположение файлов на файловой системе, и использование одинаковых
версий библиотек, и единый подход к конфигурации компонентов. Например,
в java, nodejs, python-certifi и многие другие места, работающие с TLS
внесены изменения, чтобы уметь находить system certificate store в
/etc/ssl/certs. Если я, как администратор машины, захочу доверять
некоторому CA, то мне нужно будет сделать одно понятное действие, а не
разбираться с каждой прикладной программой по-отдельности. Те же
аргументы применимы к service management, number (uid/gid/...)
assignment, vulnerability management, проблемам обратной совместимости
и многим другим инфраструктурным вещам. Чем больше таких проблем будет
решено, тем более целостной и предсказуемой будет система для
пользователя, тем меньше особенностей этому пользователю придётся
запоминать и учитывать, а значит будет проще эксплуатировать систему.
Разбиение vendor tarball на отдельные библиотеки позволяет не только
дотащить до пакетного менеджера знание об используемых библиотеках, но и
решает административные проблемы - назначает ответственного мейнтейнера
за каждый компонент в системе. Если одной программе нужна старая версия
из-за наличия в ней бага, то стоит эту программу попатчить - либо силами
разработчика (реализовать run- или compile-time feature detection), либо
силами мейнтейнера пакета; и использовать ту версию, которой будет
пользоваться большинство программ.
Конечно же, существуют альтернативные подходы к решению этой проблемы:
можно позволить держать в системе несколько версий одной библиотеки, как
в Nix; можно таскать всё с собой и класть рядом с приложением, как это
делают проприетарные программы; можно использовать статическую линковку
и перенести сложность от мейнтейнера пакета в тулчейн и голову
разработчика или вовсе забить на всё это и превратить систему в помойку
(как это часто делают в докер-контейнерах).
Не всегда пользователь заинтересован решать эксплутационные проблемы.
Разработчику прикладной программы может быть интереснее добавить новую
полезную фичу в свою программу, и хорошо бы, чтобы было поменьше
инструментов, с которыми придётся ему помучаться, чтобы достичь нужного
результата. Для этой задачи может быть удобнее использовать ad-hoc
решения (npm, go get, virtualenv, pip install, rvm, ...) вместо
общесистемных. Мне, например, очень нравится возможность NixOS делать
одноразовые окружения с любыми версиями нужных мне зависимостей
(nix-shell -p ...) для экспериментов, но большинству пользователей такая
возможность вряд ли когда-либо пригодится.
На мой взгляд, у выбранный в Debian подход выигрывает за счёт простоты
реализации (на уровне policy системы запрещаем иметь несколько разных
версий библиотеки) и предсказуемости для пользователя (policy
определяет, где что лежит). Это упрощает интеграционное тестирование
всей системы в целом, что увеличивает стабильность Debian, как продукта
и делает пользователя (принадлежащего целевой аудитории Debian) более
счастливым.
From: Sergey Matveev
Date: 2021-09-22 21:01:38Z
*** kmeaw [2021-09-21 23:43]:
>Просто у разных людей разные цели.
В целом то, конечно, согласен со всем написанным. И поддерживаю и
понимаю стремление сопровождающих делать целостное окружение. Но когда я
вижу в какой ад превращается опакечивание, казалось бы простого, NNCP --
это всё выглядит крайне удручающим.
Разработчик тратит время и силы чтобы сделать целостный tarball, чтобы
больше никаких зависимостей не тянуть, собирать без Интернета, иметь
всякие redo цели для удобной сборки зависимостей, включения готовой
документации (info, HTML-ы), а тут... в Debian делают буквально всё
противоположное: пилят на зависимости, самостоятельно собирают
документацию, буквально повторяют цели уже описанные в .do файлах
(которые ведь можно было бы выполнять даже типа как-нибудь:
redo-ifchange=пустышка . ./whatever.do, ведь это же просто shell
скрипты).
То есть, как будто, всё в Debian экосистеме заточено под работу с
паршивыми do-fuck-as-you-want самонедостаточными tarball-ами, где
никаких чётких привязок (ну типа какая-нибудь OpenSSL версия да должна
подойти). И я согласен что таких большинство, де факто большая часть
софта именно в таком виде разработчиками и распространяется. Но
"портить" или тратить уйму сил на переизобретение того что уже
специально сделано для минимизации проблем?
Я помню что от меня хотели чтобы были man-page-ы для NNCP в FreeBSD
(собственно, это единственное место где я самостоятельно добавил порт).
И вот идти мне на то, чтобы тратить уйму времени на выполнение ущербной
работы по поддержке ущербного формата (само собой, это исключительно моё
мнение, но оно непоколебимо касательно вопроса man vs info)? Хотя и
maintainer-а можно понять: раз в этой ОС/дистрибутиве принято вот так,
то никак иначе, а то будет анархия, никакой целостности и всего такого
подобного. В общем... maintainer думает что как его задолбали эти
разработчики, все со своими вкусами и принципами, а разработчикам не
нравятся когда их труд переделывают или портят :-). Но мне тошно видеть
как много времени тратится на плохой (с моей точки зрения подход) --
очевидно я бы хотел чтобы это время лучше тратили на перевод всего
имеющегося на что-то более актуальное и правильное. Небось где-нибудь
бывают и правила же чтобы проект имел autoconf обязательно.
Но я и не исключаю что это NNCP Debian-maintainer немного странный
человек, ибо он где-то в рассылке сказал что изменение в cpuid
зависимости не стоило создания отдельной библиотеки. Тут уж я
категорически не согласен, ибо в Go жёстко и чётко говорится что
whatever и whatever/v2 и whatever/v3 это три разных библиотеки, точка.
Пускай они объединены возможно в одном репозитории, но это три разных
программы, три разных зависимости, никак иначе. Но если это "хотелки"
именно Debian Go-шников, что "/v2"-появление не означает создание
golang-whatever-v2 пакета, то... это по сути просто буквально не
работающий подход в принципе (для Go).
А так то я из года в год всё меньше и меньше полагаюсь на системы
пакетов. И чисто идейно и концептуально Nix выглядит как самая
правильная штука. Нет, Nix я не буду пробовать использовать из-за его
функционального языка, а NixOS рекомендовать из-за systemd, но концепция
мне очень нравится, всячески одобряю.
>вовсе забить на всё это и превратить систему в помойку
>(как это часто делают в докер-контейнерах).
Во, тоже хорошая характеристика и причина почему Docker у многих
ассоциируется с чем-то мерзким и нехорошим :-). А ведь действительно его
часто и используют чтобы вообще абы как да засунуть всё вместе чтобы
хоть как-то запустилось.
>Разработчику прикладной программы может быть интереснее добавить новую
>полезную фичу в свою программу, и хорошо бы, чтобы было поменьше
>инструментов, с которыми придётся ему помучаться, чтобы достичь нужного
>результата. Для этой задачи может быть удобнее использовать ad-hoc
>решения (npm, go get, virtualenv, pip install, rvm, ...) вместо
>общесистемных.
Да и, более того, общесистемные вещи будут OS/distribution-specific,
поэтому с ними и не хочется возиться. А если пишешь на Python, то уж pip
то наверняка будет (как и npm, go get и прочее).
>На мой взгляд, у выбранный в Debian подход выигрывает за счёт простоты
>реализации (на уровне policy системы запрещаем иметь несколько разных
>версий библиотеки) и предсказуемости для пользователя (policy
>определяет, где что лежит). Это упрощает интеграционное тестирование
>всей системы в целом, что увеличивает стабильность Debian, как продукта
>и делает пользователя (принадлежащего целевой аудитории Debian) более
>счастливым.
Не могу не согласиться. Но для разработчика это зачастую наоборот палки
в колёса, ибо уйму раз хочется (нужно!) иметь несколько версий одной
библиотеки. Как всегда снова всё свелось к нуждам пользователей и нуждам
разработчиков :-) -- и в очередной раз их хотелки на разных чашах весов.