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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Дисциплина оформления пакетов.

1. Обновление. Кроме того, чтобы собирать, пакеты ещё надо обновлять.

1. Локальное хранилище.

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

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

  1. вз-е с пользователем
  2. оповещения

1. автосборка (пришел робот и пересобрал с новым либц)