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, и системе контроля версий.

Очередной боян про «ещё один уникальный пакетный менеджер который решит любые проблемы всех страждущих»

И да мой внутренний gentoo-шник не приемлет мерзость этого вашего paco. Но да кое-что оттуда можно и даже нужно позаимствовать в portage.

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

Вот только прежде чем делать всё это дерьмо paco -lD --ignore-erors — make install сперва таки нужно чем то удовлетворить зависимости собираемого пакета. Сюрприииз! А так как это ваше paco судя по всему этим не занимается то... ОЙ

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

短刀, при правильном применении, разрешает самые невыносимые муки.

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

Витус Вагнер?
Этот тот, старичок-завсегдатай РУ.Линукс?
Что он там несет про 100-500й гуртовщик пОкетов?

:-))
шучу конечно.

но почитал и не понравилось

Deleted
()
Ответ на: комментарий от init_6

сперва таки нужно чем то удовлетворить зависимости собираемого пакета. Сюрприииз! А так как это ваше paco судя по всему этим не занимается то... ОЙ

Там по треду вроде как есть ответ на этот вопрос. Вообще, я это всё не пробовал, но вроде как предлагается решать вопрос добавленными скриптами из Makefile, в том числе и по зависимостям. Не меняя исходных программ.

Мне это не совсем нравится, потому что, как мне кажется, можно упереться в итоге в те же проблемы и получится замена шила на мыло.

anonymous_incognito ★★★★★
() автор топика

вспомните хотя бы подрыв Линукса с помощью systemd

Что-то я подрыв Linux'а не вижу. А вот подрыв пукана автора этих строк заметен даже в Сибири.

EXL ★★★★★
()

А deb-пакеты разве не так устроены?

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

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

И всё скатывается к тому, что как и 20 лет назад, они плевались от предложений нубов заделать в ляликсе %ROOT%/Program Files, так и в 2015 году всё те же грабли пропагандирует.

А в Apple OSX таки нубам сделали красиво, как это возможно на сегодня.

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

А Филипп Киркоров уже больше 20 лет в музыке.

alix ★★★★
()

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

anonymous
()

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

чем это лучше slacktrack?

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

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

Как гриццо успехов чо! Только к чему было сюда это приносить?

init_6 ★★★★★
()

Про вред бинарных реп - правда, остальное немыслимый бред.

подменяет их через LD_PRELOAD механизм

LD_PRELOAD механизм ненадёжен, ибо отключается переписыванием окружения. Но утилита которая давала бы какие-то гарантии (работающая через ptrace, например) - вообще, неплохая идея.

только подкладывать информационные текстовые файлы (с зависимостями, версиями и т.д.) внутрь tar-архива

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

центральные depositories, которым вы обязаны верить

Только ущербные пользователи бинарных дистрибутивов. В нормальных source-based системах (как freebsd порты) никому верить не нужно - порт можно посмотреть глазами (а он маленький) и убедиться что ничего лишнего он не делает. При этом он же содержит SHA256 апстримного тарболла, что увеличивает доверие, т.к. все пользователи точно используют одни исходники, причём те же что мантейнер. Внедрить что-то таргетированно нельзя. Из портов собираются и бинарники - хотите берите готовые если доверяете сборочной инфраструктуре, хотите собирайте сами.

абсолютно все postinstall scripts создатели distros обязаны

Просто ПНХ.

делать на стандартной shell (e.g. bash)

bash - не стандартный шелл.

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

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

В общем, автор - очередной недоделанный кулибин с «покушать принёс».

slovazap ★★★★★
()

Чудеса просто. Чем это отличается от слаки? Нет, надо пойти еще дальше, в 93 год, фряха и ее порты. Вот там нету никаких пако-яко. Чистый Makefile. Вот так надо делать!

gh0stwizard ★★★★★
()

Я с этим полностью согласен. При установке, например, Opensuse, надо использовать SRPM-пакеты. Это позволит собирать сразу с march, а также использовать один ISO для всех архитектур! В начало можно ставить #define с теми несколькими параметрами, которые можно поменять без риска получить ошибку компиляции. YAST должен их определять, и позволять поменять параметры по умолчанию - что-то вроде FreeBSD, только «лицом к пользователю».

А не было это сделано не потому что «хотели сделать как в DOS/Windows», а потому что во времена Pentium это было страшно долго! Сейчас мощности позволяют установить систему за 3 часа со всеми LibreOffice и Firefox.

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

проблема в том, что он уже овер 20 лет в линукс-теме.

С паразитами вообще трудно бороться, вот ЛОР подхватил анонимуса и теперь, похоже, тоже лет 20 вывести не получится.

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

Между прочим, для Ъ - это мнение не Вагнера, чей журнал. Он тему о другом завел, что всякие CPAN'ы параллельно менеджерам пакетов - ересь.

anonymous_incognito ★★★★★
() автор топика

никогда не использовать ничего кроме стандартных инструментов (e.g. tar.gz)
Все, абсолютно все postinstall scripts создатели distros обязаны делать на стандартной shell

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

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

А не было это сделано не потому что «хотели сделать как в DOS/Windows», а потому что во времена Pentium это было страшно долго! Сейчас мощности позволяют установить систему за 3 часа со всеми LibreOffice и Firefox.

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

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

Значит, макаронный монстр с ncures/гуёвиной должен заниматься сборкой пакетов? Что же это за мания такая у виндузятников всё превращать в дерьмо.

что-то вроде FreeBSD, только «лицом к пользователю».

Это уже придумали сделали почти 15 лет назад, называется Gentoo.

mashina ★★★★★
()

В этом их ОГРОМНЫЙ вред: пользователь полностью не знает, что внутри этих кем-то созданных executables

И как пако решает эту проблему?

Не позволяет поставить софт, пока ты не прочитаешь весь исходный код от и до? Не позволяет ставить проприетарщину, пока ты не напишешь разрабам и не получишь от них исходники?

Интересно, парень, кажется, порты переизобрел.

А чем отличается вера в мейнтейнера от веры в разработчика?

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

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

thesis ★★★★★
()

Этот paco porg сойдет как манагер пакетов в LFS. А автор этой статьи — неадекват.

Unicode4all ★★★★★
()

Забавно смотреть, как программист-виндузятник рассказывает, как правильно управлять линуксовыми инфраструктурами.

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

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

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

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

противно и некрасиво, но в целом безопасно и при поддержании гигиены практически незаметно.

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

anonymous_incognito ★★★★★
() автор топика

Пакеты когда-то были способами обособить distributions и подражать миру коммерческих ОС

какой бред

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

И «которой результат» - полный кошмар версионирования внутри, снаружи и вокруг докера, который хоть как-то можно устранить только переключившись на установку всё тех же _пакетов_ внутрь контейнера.

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

Если делаешь проекты по принципу сдал-забыл, то да, docker просто идеал. Главное как сдашь убежать подальше, чтобы не нашли.

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

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

Всякие цыпаны, пеары, пипы и гемы - это как перхоть: противно и некрасиво

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

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

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

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

А, ну это правильно, конечно.
Я лично всегда относился к докеру как к средству доставки первой дозы. Во что он вырастет - посмотрим.

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

Вот это, кстати, чистая правда. Кошмар, боль и страдания. Особенно когда пакеты из этих пипов завязаны на конкретные версии системных либ.

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

Тебе слово «воспроизводимость» что-нибудь говорит?

А что из одного и того же SRPM при сборке на разных машинах получаются вообще говоря разные пакеты?

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

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

«Без него намного сложнее строить баззворд баззворд баззворд».
Да ладно тебе. Докер - средство быстро запихать продукт клиенту в глотку. По крайней мере, до совсем недавних пор.

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

когда пакеты из этих пипов завязаны на конкретные версии системных либ

И вот мы приходим к очередному аспекту пакетного кошмара: народ с таким ужасом избегает статической сборки пакетов, как будто сейчас 90й год.

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

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

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

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

В нашем мире это не так. Мы сами себе и разработчик, и клиент, и у нас докер - это средство построения облаков.

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

Проблема не столько в пакетном менеджере, сколько в попытке использовать их несколько разных параллельно. Ну и статическая сборка, да, по неизвестным мне причинам считается фуфуфу (

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

Кошмар, боль и страдания. Особенно когда пакеты из этих пипов завязаны на конкретные версии системных либ

Так это вина не пипов, а как раз лохматых пакетников, не умеющих многоверсионность и лочащих либы взаимными зависимостями.

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

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

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

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

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

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

Наоборот, они прямее и удобнее штатных архаических пакетников

А я с этим и согласен. Просто, тем не менее, это все равно некрасиво и противно. Но хотя бы позволяет развести зоопарк приложений, не рассаживая их по контейнерам.

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

Докер просто удобен для этого. До него был openvz и даже немного голого lxc.

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

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

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

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

Это emdrone, что ли, автор опуса?

Нет, если только не так, что 'anonym_mouse' - это его ЖЖ.

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