Лектор собирает либреофис, а он не собирается. Пытается собирать в 32 потока на ферме с 256 гигами оперативки. Но проблема в джаве. Джава, когда её запускают, оно занимает всю память. Написана так. На всякий случай, а вдруг потом не дадут. И вот 32 джавы, каждая хочет 32 гига. Линукс не дает. Джава обижается и не форкается. Подобрали число потоков в 11, вроде лучше. В 32 потока либреофис собирается час. В 1 -- посчитайте сами.

Но это было с 3 офисом. Новый офис собирается одной командой, на которую нельзя никак влиять. Пришлось писать обертку на си над форком, которая смотрит, сколько процессов запущено от пользователя, сколько у них виртуальной памяти, и если у него 64 гига памяти виртуальной, то оно не форкается, а 5 минут ждет, а потом пробует ещё раз.

Итак, тема этого семестра "Сопровождение программных пакетоа ГНУ/Линукс". Расказанное выше -- блудни сопровождающего пакеты. Почему решили рассказывать про такой узкоспецифический продукт, как дистрибутивы линукс и особенности их создания?

О чем пойдет речь и почему это важно?

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

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

Ядро является пакетом, и если будет время поговорим про сопровождение ядер, но цель не в этом.

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

Что сюда входит?

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

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

  1. Управление пакетами (говорили полтора года назад, наверное стоит повторить) Как их устанавливать, удалять, итп.
  2. Интеграция пакетов друг с другом. Как так вышло, что несколько тысяч пакетов из хранилища внезапно работают друг с другом и им хорошо.
  3. Хранилища пакетов -- зачем, как устроены, жизненный цикл с точки зрения пользователя. Как меняется хранилище при использовании, как устроена поддержка цельности (или не устроена).
  4. Как создаются дистрибутивы. В каком-то виде оно уже было, но воспроизвести его, глядя в сторону пакетов, будет невредно.

Эта часть прозвучала в первом семестре.

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

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

Что здесь нас интересует?

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

1. Инструменты сборки делятся на две части:

  1. Инструменты разработки, которые использовались апстримом.
  2. Средства сборки пакетов.

Есть скрипты, которые позволяют из чего угодно сделать пакет. И они делают пакет. Но он не ставится. Конфликты какие-то вылезают, ещё что-то.

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

  1. Дисциплина оформления пакетов. Какое-то время вы собираете пакеты только для себя, чтобы использовать в своих реальных боевых системах.
  2. Обновление. Кроме того, чтобы собирать, пакеты ещё надо обновлять. Представьте ситуацию, есть пакет, на него 45 патчей, из них половина из редхата (хорошие, годные патчи), и тут вы познакомились с гитом, где феерическая работа с патчами, половину мерджей утонченный мозг делает сам, и так далее. И вам пришла в голову светлейшая мысль -- зачем держать патчи в виде странных разрозненных файлов, давайте держать это прямо в гите. Будет чистенький апстимный гит, и наш с патчами. При приезжании нового апстрима берете и мержите.Или делаете ребейз. Итак, вы замерджились, причесали. Вышел новый апстрим. Вы опять пытаете замержиться, и осознаете, что 10 версий назад был патч. Он уже был 10 раз перехакан, но снова вносится. У вас нарастает ком изменений к изменениям к изменениям и только большая эластичность мозга позваляет вам помнить, зачем все это было нужно. Итого, идея с отдельным хранением патчей была хорошей идеей. Итак, надо принимать решения -- либо хранить патчи, либо заниматься мерджеми, либо заниматься ребейзом. Про ребейз поговорим позже. Итого, обновление это очень непростая процедура.
  3. Локальное хранилище.

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

  1. Работа с центральным хранилищем одним или несколько. Это может потребовать от вас каких-то действий -- соблюдение дисциплины данного центрального хранилища, подписывание этих пакетов. Зато вы увидите свой пакет в центральном хранилище.
  2. Использование публичной сборочницы -- тоже бонус официального сопровождаюшего. На всем хранилище можно осуществлять контроль качества, которые сложно делать в домашних условиях, например -- держать список всех экспортируемых символов всех библиотек и проверять после сборки каждой библиотеки, что произошло со списком ненайденных библиотечных символов для вашей программы. Может быть такое, что программа собралась, но одного из нужных ей символов в библиотеке нет. Библиотека есть, а символа нет. Некоторые программы любят всякие плагины, некоторые вместо разделяемых библиотек используется буйная фантазия апстрима, есть случаи, когда отсутствие символа это нормально. Идея контроля качества -- что хуже становиться не должно. В общем, есть такие веши, которые можно проверить только сообща. Каки ещё бывают бонусы? 1.Сопровождение
    1. вз-е с пользователем
    2. оповещения
  3. автосборка (пришел робот и пересобрал с новым либц)

LecturesCMC/PackageMaintaining2013/Conspects/00 (последним исправлял пользователь Allena 2013-04-12 23:27:11)