LINUX.ORG.RU

Мнение про механизм дистрибуции программ

 , ,


1

2

Не моё, наткнулся в http://vitus-wagner.livejournal.com/1153225.html?thread=39454153#t39454153 Не готов сказать, что оно совершенно правильное, но очень заинтересовало.

make (and/or its versions) plus «paco» on Linux == the full solution.

Пакеты когда-то были способами обособить distributions и подражать миру коммерческих ОС. В этом их ОГРОМНЫЙ вред: пользователь полностью не знает, что внутри этих кем-то созданных executables, туда можно подсунуть что угодно (несмотря на криптосуммы, ибо они подписаны постфактум, и ваша вера в создателя пакета обязана быть абсолютной).

Все distros ввели собственные скрипты и методы компиляции, т.е. открытая программа как она есть НЕ становится «пакетом», она обязана быть модифицирована.

Первым преступление совершил RedHat с его rpm-ами, которые модифицировали cpio так, чтобы его перестала читать сама cpio. Нас «успокоили» тем, что сам rpm тоже открытая как бы программа - и проложили прокладку.

Единственно верный подход к package management - никогда не использовать ничего кроме стандартных инструментов (e.g. tar.gz), и только подкладывать информационные текстовые файлы (с зависимостями, версиями и т.д.) внутрь tar-архива. Можно на худой конец и cpio, и сжимать xz-м, bz-ом и т.д. Тогда любая стандартная GNU программа компилируется как она есть.

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

Он ловит обращения к libc calls, system calls - и подменяет их через LD_PRELOAD механизм. Таким образом после стандартной компиляции make install превращается в «paco -lD --ignore-erors — make install» — и ваш пакет учтен, все файлы и их места зафиксированы, размеры посчитаны — и из этой установки можно тут же сгенерировать tar.gz для повторной установки на любых других машинах.

Множество менеджеров пакетов, отказ от компиляции непавленных исходников, и перевод пользователей на центральные depositories, которым вы обязаны верить - часть той войны за захват открытого программирования, которая сегодня ведется повсеместно (вспомните хотя бы подрыв Линукса с помощью systemd), и которая открытые системы постепенно побеждает, делая их кальками коммерческих ОС и механизмов слежки и отбора самостоятельности, которые они жёстко внедряют.

------------ P.S. Все, абсолютно все postinstall scripts создатели distros обязаны делать на стандартной shell (e.g. bash), и собирать их в маленький Makefile. Сказав «make» без аргументов получим перечисление возможных команд (i.e. make targets), и затем говорим то, что нам надо в случае пакета. //очевидно, что этот подход универсален и может использоваться как для модулей языков, так и для отдельных программ в ОС//

Современная мерзость - особенно мерзость «rolling distributions» - непереносима.

P.P.S Современные системы configuration management - мерзость и непереносимы. Они ПЕРЕПИСЫВАЮТ внутри себя кучу уже существующих shell utilities, make и т.д. - и вместо полной гибкости и стандартных инструментов предлагают учить новый внутренний их язык, на котором можно сделать лишь то, что вам написали авторы.

Необходима современная открытая configuration and package management system, основанная на paco, make, и системе контроля версий.

Ответ на: комментарий от anonymous

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

Да всё теже проблемы, например, внезапно выясняется, что нужна другая версия перла на RHEL. Потом внезапно выясняется, что модуль из цыпана биндится к какой-то сишной либе, которую ещё надо компилять и что в текущем компиляторе нет каких-то фич или наоборот его приблизили к стандарту. И т.д. А ещё могут начаться конфликты с другими библиотеками и пошли-поехали «дикие пляски»

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

Потом внезапно выясняется, что модуль из цыпана биндится к какой-то сишной либе

Это не так часто встречается, и для таких случаев есть системные пакеты обычно. Гемор чаще от того, что нет инструмента, синхронизирующего окружение разработчика и целевой системы. Еще раз пропиарю рубиновый бандлер, но без него действительно тяжко. Не знаю есть ли подобное для перла, должны были уже запилить за эти годы. Впрочем ССЗБ могут такими инструментами не пользоваться. Защиты от дурака не придумали пока.

anonymous
()
Ответ на: комментарий от alpha

Это не повод её увеличивать.

Её же не просто так увеличивают, а в обмен на гибкость. Бинарные дистрибутывы жутко неповоротливые даже для обычного использования.

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

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

mashina ★★★★★
()
Ответ на: комментарий от mashina

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

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

alpha ★★★★★
()
Ответ на: комментарий от anonymous

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

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

mashina ★★★★★
()
Ответ на: комментарий от mashina

дебиан

будешь трахаться

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

anonymous
()
Ответ на: комментарий от thesis

помимо tzdata в мире есть и другие либы.

Да, и если они запакованы в бинарник/program files то не будут обновлены, пока автор софтины не почешется, чего может вообще никогда не случиться. А в обновлениях будут фиксы и залатанные уязвимости, но оно нам не надо, главное ведь убежать от пакетного менеджера.

legolegs ★★★★★
()
Ответ на: комментарий от legolegs

Ты, если уж примерил на себя капитанскую фуражку, то хотя бы задумайся хоть на секунду, что лучше: иметь работающую непроапдейченную софтину, или неработающую вообще.
И вообще, перестань уже вести себя так, как будто я написал «ВЕСЬ ЮЗЕРСПЕЙС НАДО ЛИНКОВАТЬ СТАТИЧЕСКИ И НИКАК ИНАЧЕ».

thesis ★★★★★
()

Необходима современная открытая configuration and package management system, основанная на paco, make, и системе контроля версий.

0install ?

anonymous
()
Ответ на: комментарий от thesis

И упадёт хранилка )) Как scalability будешь обеспечивать с зоопарком на одном хосте? Да хотя бы воркеров добросить: оппа, порт уже занят.

leave ★★★★★
()
Ответ на: комментарий от leave

И упадёт хранилка ))

Почему она вдруг упадет от одной ноды, но не упадет от нескольких?

обеспечивать баззвордабилити

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

Да хотя бы воркеров добросить: оппа, порт уже занят.

Ты это щас серьезно? Я либо не понял вопроса, либо не вижу проблемы.

thesis ★★★★★
()
Ответ на: комментарий от thesis

Почему она вдруг упадет от одной ноды, но не упадет от нескольких?

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

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

Ну так я не говорю сейчас о потребностях этих организаций. Пусть этим занимается эрзент )

Ты это щас серьезно? Я либо не понял вопроса, либо не вижу проблемы.

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

leave ★★★★★
()

Эй, redhat уже всё придумал для вас, xdg-app уже в fedora тестируют.

pod ★★
()
Ответ на: комментарий от leave

Ты зачем-то приписываещь контейнерам бонусы микросервисной архитектуры. При том что это две независмые вещи.

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

Ну и микросервисы, кмк, в массовом сознании уже неразрывно связаны с контейнеризацией.

leave ★★★★★
()
Последнее исправление: leave (всего исправлений: 1)

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от leave

когда у нас контейнеры на хардварных нодах - хранилки становятся не нужны

А данные где?

Пусть этим занимается эрзент )

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

две-три сотни разных приложений-микросервисов

Люди, ... нутыпонел. Причем это даже не ынтерпрайзъ, это хрен знает что и вообще какой-то коллцентр на юпитере.
Нет, я понимаю, что ты решаешь важную задачу в своем сегменте. Но ты внемли голосу малых сих: представь контору, имеющую штук пять кастомных и пять типовых приложений (пусть все они вебня) для внутреннего пользования, и развернуть эти приложения на одной системе это АДЪ АДЪ ПАКЕТЫ КРОВЬ КИШКИ НАМОТАЛО НА КУЛЕР. А людям всего лишь хочется иметь один виртуальный вебсервер вместо пяти и уютно его бэкапить по ночам. Это мелочь, но она досадна именно тем, что она совсем никому не несет плюсов, а гемор - несет.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

... а ведь тролли 5-10 летней давности никуда не исчезали по закону сохранения энергии ... подумалось ...

anonymous
()
Ответ на: комментарий от thesis

Почему вообще начало считаться, что статическая линковка — это приемлемо? Как по мне, это говно, которое надо выжигать нахрен, за исключением случаев, когда софт не работает и не собирается с новой версией либы. В таких случаях статическую линковку (или динамическую со своими копиями в /usr/lib/$pkgname и RPATH) нужно применять точечно для конкретного пакета, как это недавно делали в арче для libreoffice. В случае слома ABI — да, все зависимые пакеты подлежат пересборке.

Или в нашем дивном новом мире разработчики разучились следить за ABI, а мейнтейнеры — следить за тем, когда его ломают? Круто, чо.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

Единственно верный подход к package management - никогда не использовать ничего кроме стандартных инструментов (e.g. tar.gz), и только подкладывать информационные текстовые файлы (с зависимостями, версиями и т.д.) внутрь tar-архива. Можно на худой конец и cpio, и сжимать xz-м, bz-ом и т.д. Тогда любая стандартная GNU программа компилируется как она есть.

man 7 archlinux

man 5 PKGBUILD

intelfx ★★★★★
()
Ответ на: комментарий от leave

У тебя реально уже совсем понты от ынтерпрайза голову сломали.

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

К тому же я скоро может снова будут при своём дата центре, хоть и не хочу особо нервы себе портить, ещё 3 собеседования, с тех диром, диром по развитию и геной.

Спокойная работа и з\п выше 60 шт походу исчезли...

erzented
()
Ответ на: комментарий от leave

хранилки становятся не нужны. Live migration тоже становится не нужен, кстати.

Весьма спорное утверждение.

За счёт возможности отказа от использования хранилки повышается отказоустойчивость

Как куча наколенных костылей может повышать отказоустойчивость? :)

и снижается общая стоимость владения.

CAPEX может и будет ниже, а вот OPEX обычно таки нифига.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

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

Где ты увидел костыли я хз.

leave ★★★★★
()
Ответ на: комментарий от leave

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

erzented
()
Ответ на: комментарий от leave

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

erzented
()

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

Пользователь полностью не знает, что внутри этих кем-то созданных Makefiles (не говоря уж об исходниках собираемого ПО), туда можно подсунуть что угодно. Дальше не читал.

dexpl ★★★★★
()
Ответ на: комментарий от leave

за счет внедрения системы оркестрации и переделки под нее все инфраструктуры.

Что мешает использовать оркестрацию с хранилками?

Где ты увидел костыли я хз.

Все эти drbd и ко зачастую ими и являются.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

Какие drbd? Я говорю про обычные стоечные серверы, без хранилок вообще. Они просто не нужны в том сетапе, что я описываю.

leave ★★★★★
()
Ответ на: комментарий от intelfx

Почему вообще начало считаться, что статическая линковка — это приемлемо?

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

В таких случаях статическую линковку (...) нужно применять точечно для конкретного пакета

Я ж и не говорю «давайте слинкуем статически все, до чего сможем дотянуться».

Или в нашем дивном новом мире разработчики разучились следить за ABI, а мейнтейнеры — следить за тем, когда его ломают?

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

thesis ★★★★★
()
Ответ на: комментарий от thesis

100 литров чая этому господину! Я уже не дождусь, когда сделают линукс, в котором сами разработчики смогут сами собирать свои либы, и юзер сам сможет ставить любые какие хочет, хоть все.

OpenMind ★★★★
()
Последнее исправление: OpenMind (всего исправлений: 1)
Ответ на: комментарий от thesis

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

RPATH + /usr/lib/$pkgname (/opt/$pkgname в совсем тяжёлых случаях)

Еще потому, что существуют всякие юсб-накопители и такая удобная временами штука, как таскаемый в кармане набор софта.

LD_LIBRARY_PATH / chroot

в действительно дивном новом мире такого понятие как «мейнтейнер пакета дистрибутива N» не должно существовать вообще

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

Ну а если запретить мейнтейнеров и не устроить единый репозиторий — тогда да, только статическая линковка и только винда (а-ля google://скачать $pkgname).

Punchline: динамическая линковка никогда не хуже статической. Пакетная система бывает неудобна, но она необходима для того, чтобы не получилась вторая винда. Идеальный мир достижим только через «единый x ∀x» (т. е. недостижим).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 6)
Ответ на: комментарий от intelfx

Я тебе пишу «не хочу гемора», а ты мне - «гемор разруливается так-то и так-то». Я не хочу его разруливать, я хочу, чтобы его просто не было.
Кроме того, статическая линковка - это не основная тема, это так, по касательной.

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

Именно. Я и говорю - msiexec installd.

А будет ли в нём статическая или динамическая линковка — абсолютно пофиг.

Да. Личное дело автора, он же майнтейнер.

если перевести все дистрибутивы на статическую линковку всего

Да хватит уже спорить с голосом в голове. Тем более, это не мой голос.

thesis ★★★★★
()

Сам маэстро a.k.a. Лёня Горшков год назад нафантазировал в бложике про фреймворки приложений и сами приложения в подтомах btrfs и что-то такое, причём его фантазия была и раньше, и куда эротичнее чем велосипед, который ты принёс. Правда, по какой-то причине, ничего не материализовалось (давайте подумаем кому это могло быть выгодно почему).

d_a ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.