В прошлый раз мы говорили про пакеты и в основном наш разговор крутился вокруг уже бывшего в предыдущем семестре материала. Сегодня лектор попробует немножко продвинуться вглубь этого дела.
Несколько важных вещей которые надо было подсмотреть лектор не подсмотрел в силу болезни. но разговора на сегодня должно хватиьт. Вопросы в прошлый раз после лекции показали, что тема целей проектирования в разных системах не была раскрыта, эту тему хочется раскрыть прибавив, зачем всё это происходит.
Есть некая ос, и в нее вы собираетесь установить программынй продукт, который есть в исходных кодах. Не рассматриваем сейчас работу с бинарниками, потому что в ней очень много неинтересных подводных граблей.
Как уже говрилось есть один способ -- крибле-крабеле -бумс -- коняигуре-маке-макеинсталл. Скачиваете сырцы сч апстрима, находите там инструкцию, запускаете то-то сё-то. Ручная сборка и установка.
Установка и пакетирование
Пока что мы действуем в рамках парадигмы людей которые не собирают пакеты. а пытаются затолкать по, такихе, пользователи своего компьютера. Возможно некоторым кажется. что ручсная сборка -- самый простой способ добиться работоспобности пп. Вы работаете с исходным кодом автора, следуете его инструкциям, у него все работало, у вас тоже должно,к азалось бы. Вы -- скрипт кидди, вам сказали вводить комманды. вы ихх вводите. Этот метод плох всем, он хорош только для разработчиков.
Недостатки
Начнем с того, что никакой ручной сборки не произойдет, елси не поставить в систему сборочные зависисмости (и это не толькокомпилятор! Библиотеки, сборочные инструменты, всё должно стоять в вашей системе.) Почему это плохо -- вы сами не знаете каие они етсь, и это самое крибле краблебумс, превращается крибле, крибле. крибле и ммежду ними вы обнаруживаете, чего не доставлено в вашу систему. Даже если конфигур и мейк отработают -- это ещё не будет значить, что все хорошо. эНе стояло у вас либжпг, автор писал его так, что он без него собирается. но никакие жпеги нео открывает, например. Определить все зависимости -- сложно.
Отсутствие привязки к дистрибутиву. Вы делаете как рекомендовал автор, это может быть не так, как принято в вашем дистрибутиве. Вы и сами не очень хорошо представляете, как это происходит, но есть ощущение, что автор имел ваш дистрибутив в виду каким-то особо извращенным способом.
Маке инсталл надо говорить от рута. Вы выполняетет от рута непонятно что, написанное непонятно кем. Установка от суперпользователя -- тоже недостаток. Не очень это приятное занятие -- запускать маке инсталл от рута на живой работающей системе. Алтернатива -- создание проектов, которые не требуют установки, а работают там где собрались. или работают из домашнего каталога. Собранный так пп скорее всего будет работать только у вас и скорее всего не будет работать как надо.
Ручная установка редко приводит к желательным результатам и как только компьютеров становится больше одного и польователей много -- установка от рута становится очень неудобной.
Совершенно не факт, что криблекрабле-бумс удастся сделать, даже если все делаете как написано. "А если не сработает?"Все сказали как написано, а у вас ничего не вышло. Если вы не програмист.ю не разработчик линукса, или не слишком поытный разработчик линукса -- это все достаточно сложные препятствия.
Как выйти из этого положения?
Необходимо вмешательство опытного человека, который бы поглядел на локальную установку, и написал бы рецепт установки данного пакета для данного конкретного дистрибутива. Спецификация сборки и установки содержит:
- какие зависимоти для сборки
- команды для сборки
- команды для установк
Это решает проблемы с отстутвием информации о дистрибутиве и сборке. Так до сих пор поступает фрибсд. В порт хранятся мейкфайлы и патчи. Когда в бзд говорите маке чего-нибудь в дереве портов, самостоятельно порт скачивает исходник нужной версии из апстрима, разворачивает и сообразно специально мейкфайлу к нему приложенному делает с ним, что надо. Скачивает, запускает сборку, подправляет, раскладывает резудьтат.
Этим проблемы за вас решаеткакой-то счеловек, окторый понимает сбборочные зависимости, знает специфику данного дистрибутива и принимает отвтетсвенное решение как собранный пп разместить в дереве катлогов ос так, чтобы ничего не испортить.
про установочные завсимсоти сейчас вспомним. Сами они при таком подходе не удовлетворяться.
Во фре если не хватает установочных зависимостей, значит они тоже не собраны, и они станут сборочными зависимостями(?). минусы.
Установка сборочного окружения остается. Все равно остается нужной.
Сборка длиться долго (поди собери опенофис), процесс сборки надо запускать.
альтернатива -- скачать бинарник, понадеяться, что он заработает.
Рецептура должна быть актуальна. Она должна учитывать реалии как версии апстрима, так и среза дистрибутива на вашей конкретной машине.
Главный недостаток -- надо соблюдать актуальность рецепта, и это дважды двухсторння проблема -- рецепт должен соответствовать версии продукта в апстриме и сборочному окружению, и эту актуальность должен соблюдать и человек пишущий рецепт, и человек, рецепт использующий.
Состовитель рецептов зовется майнтейнер. Раз уж он сотоавил спецификацию сборки, то наверное он его собирал (если это не так, надо его наказать и покрыть презрением). Если он его собирал, то может он и состоавит пакет бинарный?
Бинарный пакет
Говорим составителю рецепта -- претвори его в жизнь, и в конце результат положи в архив. В той же бзд это делается. Казалось бы мы решили много проблем -нам не надо самим собирать, нам не надо ставить уст. окружение, только разложить файлы.
Главная пробелма -- установочные зависмости. Раньше мы это не так замечали, потому что обычно сборочные зависимости вытягивают за собой установочные.
А что с генту? Идея генту -- на каждом компьютере ос уникальна -- это основная идея.
Ещё одна проблема с бинарными пакетами -- товарищ собрал пакет, в не мпроставились зависимости. В спеке описаны сборочные и установочные зависимости. Берете пакет, начинаете ставить, и выясняется, что у вас библиотеки с теми же названиями и другими версиями, и взять библиотеки с нужными версиями неоткуда. Согласованность. Здесь возникает идея дистрибутива. она не только в том, что вы берете программы все компилируете, ставите и у вас есть ос. Она состит в том, что эти бинарники таки можно все вместе поставить и они таки да, будут вместе работать. Что в данном случае не гарантируется.
Согласованность по:
- зависимостям
- установке
- черт знает по чему
- специфике дистрибутива
Главное - согласованность по зависимостям. В след раз будем говорить об унификации сборочного окружения. Когда отправляешь пакет в хранлилище он должен быть собран в условиях, когда воекруг пакеты, синхронизированные с хранилищем не дальше недели назад. Так было 20 лет назад. Сейчас это не так, потому что этот интервал уменьшился до отрицательных значений -- пакет собирается, а его сборочные зависмости уже обновились, потому что собираются сто паакетов параллельно.
Представим, что мы 15 лет назад.
Все это наводит нас на мысль, что нужен пакет, а не программный продукт.
Здесь сделаем паузу в поступательном движении, потому что вдаемся в область сборщика пакетов, про которыую будем говорить позже, а сейчас мы рассуждаем, как пользователи.
Вернемся к теме разныйх способов пакетирования программных продуктов. Ключевым местом в вопросе "как создать пакет?" будет то, интерферируют ли программные продукты, когда мы их пытаемся ставить в нашу систему.
Вариант номер один
Программные продукты интерферируют, но мы за это не отвечаем. Мы вместо этого предоставляем разработчикам достаточно полную ос, базовая ос будет достаточно большая, в ней будут в том числе средства разработки. Встаем в снобскую позицию и говорим -- базовая ос дает вам все что вы хотите, все остальнное на ваше усмотрение, если вам надо ещё что-то -- таскайте это с собой. В переложении в мир опенсорса вы получите пакет, таскающий с собой всё, чего иногда не хватает в ос -- либпнг, жаву, питон неокторые таскают. Пакет-дистрибутив, в окторый входит все, кроме ос. что ему нужно, чтобы запуститься.
Очевидное главное свойство окружения, сформированного с такими пакетами это большое необходимо в обратную сторону, необходимо большое базовое окружение, включая базовое сборочное окружение.
Типичный пример ос, построенной по принципу пакет-дистрибутив это виндоус. Проблема в том, что виндоус не явлеятся хорошим полным базовым окружением, особенно в том, что касается разработки. Поэтому в случае виндоуса этот подход не очень хорош. Возникает беда разноверсицы, это беда человека, который агрессивно пользуется виндоусом. Есть даже кажется инструменты для хранения истории дллек, чтобы моно было откатиться, но обычно делается только хуже.
Был такой скандал в виндоус 3.0. Тот апи который был предоставлен партнерам был явно не полным, и с его помощью нельзя было написать нормальный программный продукт. Надеяться на большое базовое окружение не стоит. Как выйти из этой ситуации.
Способ номер два
Признать, что пакеты не интерферируют друг сдругом. Нужно написать ос, в которой можно нормально организовать работу программ так, чтобы пакет равнялся изолированному окружению. Первое главное требование -- наличие поддержки изолированных запусков со стороны ос. Во-вторых, поддержка взаимодействия изолированных окружений средствами ос. Видимо, должен быть набор базовых библиотеК, который все таки общие. Но, поскольку мы заранее договораиваемся, что окружение изолированное, эти общие билиотеки должны быть рокстейбл. Когда они меняются,все наши партнёры перекомпилируют все свои программы. Редко изменяеоме базовое окружение. Главный недостаток такого подхода -- ресурсы.
Если каждый продукт работает изолиронно, то возможно много раз грузятся одни и теже билиотеки и ставтяся одни и те же зависимости. олне возможно, даже цпу они бы оедали меньше, если бы знали друг о друге чуть побольше.
Главное преимущество -- программы можно писать как угодно.
Нам с вами все это недоступно. Первая часть -- потому что в любом случае будет разноверсица, слишком много людей. Общую рабочую среду сделать не можем. Вторй способ тоже плохо подходит, хотя идея создания такого рода линукса виает в воздухе. Это непрерывный разговор последние лет 12, но все никак не взлетает. Недостаток -- мы не имеем профита от сообщества.
Путь номер три
Признаем, что пакеты интерферируют. Разрабатываем инструмент, который с этим работает, как на уровне пакета, так и на уровне хранилища. Согласованность. Будем говорить, когда будем говорить о жизненном цикле хранилища.
Как пользователи подключенные к хранилищу мы приобретаем гарантированный способ устанвоки пакета. Ситуация, когда не работает пакет взятый из хранилища связан с реальными нарушениями на машине (поудалял половину файлов, или пересобрал руками гном, или какую-нибудь библиотеку важную собрал руками старой версии, а пакет с новой не поставил). Может быть и проблема состороны хранилища, но с этим реально борются. Правда, это соблюдается только втом случае, если хранилище одно. Таким образом наше разделение на установщики и диспетчеры обретает дополнительную мотивацию. Установщики это те, кто обеспечивает историческую часть вплоть до возможности установить пакет из бинарников. А диспетчер пакетов, работающие с хранилищем, работают с новым, появившимся после того как мы отработали версию пакет=пакет, работают с проблемами внутри хранилищ. Какие там могут быть проблемы? Например определить список пакетов, которые нужно поставить вместе с нашим, скачать их и поставить, если хранилищ несколько, понять из какого скачивать.
Что здесь можно вспомнить. Установщик пакета -- помимо того, что он отслеживает чек сумму и так далее. Помимо всего прочего пакет подписан электронной подписью, список открытых ключей хранится в специальной базе и при установке пакета можно проверить, кем он подписан. Это один из серьезных бонусов, которые отлисали свободный софт несколько десятков лет. Современные бинарные хранилища не хранят пакеты, собранный майнтейнерами, они хранят результаты работы сборочницы. Майнтейнеры только присылают рецепты. Появление вредоносного кода возможно толкьо если его туда внес майнтер пакета или сборочница, будучи взломанной. Именно пожтому хакерские сообщества типа блэкхэт рассчитаны на то, чтобы взламывать сборочницы дистрибутивов. Один раз с дебианом, другой раз с редхатом они этого добились. Вторая причина сложности заполучить вредоносный код на открытых системах, что скорее всего там не будет вареза (или его булет мало).
пары установщик-диспетчер: дпкг-апт для дебиана, у убунтыслучай особый, поговорим чуть позже. Редхат -- rpm и yum. В suse установщик rpm, диспетчер zipper. yast -- это такой хитрый конфигуратор.
В альтлинуксе очень хотят отказать от апта. Он безумно долго работает. Написан на си плюплюс хакерами.
Нам, как пользователм, все равно, как называются инструменты для установки и удовлетворения зависимостей.
Что касается убунты, надо сделать отступление. В багзилее пункт номер один -- достижение мирового господства. Помимо общих идея создания линуксовых дистрибутивов у убунты есть идея захвата рынка и расширения количества людей, ею пользующихся. Этого нельзя рподелать без сдивга планки от удобства для коммьюнити и безопасности в сторну простоты и удобства доставки пакета до пользователя. Любое нечто, ориентированное на массовое употребление...
Отвлечемся. В случае винды, в случае пакет-дистрибутива и случая, когда туда понаставили 100500 программ и они друг другу мешают. Если ставтиь туда столько игрушек, сколько смогли купить, они друг другу не мешают. Один офисный пакет друг другу не мешают, один фотошоп друг другу не мешают. В офисном внедрении никто не ставит 100500 программных продуктов. То, тчонам кажется неудобстовм -- это пограничная ситуация для массового деплоймента. В виндойсе с этим не борются, потому что у 99 процентов заказчиков такая ситуация просто не возникнет, потому что им нужны 3-4 наименования программных продуктов.
Возвращаясь к убунте. Во что выливается этот сдвиг планки в сторону удобства для пользователя и простоы деплоймента? Заходите на апстримный сайт. Почти наверняка там будет пакет для убунты, потму что убунта очень популярна. Этот пакет для убунты будет собран прямо там апстримом, а вовсе не из репа убунты. Вы будете на него кликать, он будет стаивться. В худшем(лучшем) случае это будет файл с описанимем хранилища, которое добавится в список доверенных хранилищ. Если раньше считалось, что список хранилищ редактирует сисадмин, то теперь это делается одним кликом. Пользователь может не обратить внимания, что творится со списком хранилищ. Проблема с безопасноятью "немножко возросла". Потому что механизм защиты, связанный с контроллируемостью хранилища, распылился.
Ещё хуже обстоят дела с несвободными продуктами под линукс. Их становится гораздо больше, появляется свой варез. Хотя варез фейктаймом и лд_прелоадом делается очень просто, то есть глубокой культуры перехачивания бинарников нет. Но, тем не менее, ситуация, когда не котроллируется список хранилищ -- плохая ситуация. Ещё хуже она становится, когда вы понимаете, что пакеты интерфрируют, хотят разные версии билиотек. Цикл обновления хранилищ не синхронизован.
Лектору кажется, хороший способ -- вынуждать производителя помещать пакеты в централизованное хранилище. Если речь идет о свободно распространяемом программном продукте, чтобы его можно было скачивать и распространять (пусть и только в бинарниках). В альте есть несколько успешных таких вариантов сотрудничества. Таких мало. Но и редхат с убунтой не сильно развлекаются принуждением к миру.
Идея назвать базовым окружением все хранилище, а все остальное заталкивать в контейнеры -- хорошая идея. Хотя сейчас готвого решения нет.
Резюме
Что надо представлять пользователю:
- Какие хранилища надо использовать. (Бинарные, no-arch, 32 или 64 разрядные). Когда-то все компьютеры были 4-разрядные. потом 8, потом 16, трали вали. Но развитие ос в большом количестве, качестве и заполонении окр пространства пришлось на эпоху ибм-совместимых компьютеров и эпоху их 32 разрядности. Потом все переключились на 64 разрядные компьютеры. Но есть набор проприетарных програмных продуктов (виденье лектора -- люди на 15 лет отстали от жизни и до сих пор собирают программы под 32 разрядную архитектуру). С точки зрения ос запуск 32-разрядного приложения на 64-разрядной архитектуре это очень непросто, потому что нужны все 32-р библиотеки, и они должны уметь работать в парарллель с 64-разрядными такими же. В альте есть специальные пакеты, в которые вынесены только архитектурно зависимые части пакета.
В следующий раз будем говорить о том, как собираются пакеты.
- По какому принципу формируются хранилища, из которых вы ставите.