Differences between revisions 1 and 2
Revision 1 as of 2013-03-01 19:11:15
Size: 12441
Editor: Allena
Comment:
Revision 2 as of 2013-04-12 23:27:11
Size: 12473
Editor: Allena
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
О чем пойдет речь и почему это важно? === О чем пойдет речь и почему это важно? ===
Line 17: Line 17:
Что сюда входит? ==== Что сюда входит? ====
Line 19: Line 19:
 1. Когда вы разворачиваете ос, вы первым делом имеете дело с пакетом, как компонентом ОС. Возникает много вопросов, связанных с модульностью дистрибутивов.
Когда вы разворачиваете ос, вы первым делом имеете дело с пакетом, как компонентом ОС. Возникает много вопросов, связанных с модульностью дистрибутивов.
Line 31: Line 32:
Что здесь нас интересует? ==== Что здесь нас интересует? ====
Line 38: Line 39:
 Есть скрипты, которые позволяют из чего угодно сделать пакет. И они делают пакет. Но он не ставится. Конфликты какие-то вылезают, ещё что-то. Есть скрипты, которые позволяют из чего угодно сделать пакет. И они делают пакет. Но он не ставится. Конфликты какие-то вылезают, ещё что-то.
Line 40: Line 41:
 Разные дистрибутивы накладывают разные требования на структуру пакетов, чтобы обеспечить как раз ту самую интеграцию.
1. Дисциплина оформления пакетов.
 Какое-то время вы собираете пакеты только для себя, чтобы использовать в своих реальных боевых системах.
1. Обновление. Кроме того, чтобы собирать, пакеты ещё надо обновлять.
Разные дистрибутивы накладывают разные требования на структуру пакетов, чтобы обеспечить как раз ту самую интеграцию.
 1. Дисциплина оформления пакетов.
 Какое-то время вы собираете пакеты только для себя, чтобы использовать в своих реальных боевых системах. 
 1. Обновление. Кроме того, чтобы собирать, пакеты ещё надо обновлять.
Line 45: Line 46:

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

Лектор собирает либреофис, а он не собирается. Пытается собирать в 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 (last edited 2013-04-12 23:27:11 by Allena)