Пакеты и дистрибутивы
План «доклада про Linux-2020» и часть копипасты оттуда
Открытая разработка ПО и свободное лицензирование
Университетская разработка: программирование как исследование, Какие ещё лицензии; Hackerdom — в целом про то же
Открытая разработка
Основы открытого сообщества в современном виде:
(Цель очевидна: разработка ПО
) Задача: разработка силами всех заинтересованных
- ⇒ максимально простая процедура подключения к сообществу (грубо говоря, низкий порог во всём, кроме профессиональных и отчасти коммуникационных навыков)
- ⇒ максимально доступное информационное пространство (открытый публикумый исходный код, wiki-образный сайт, соцсети/рассылки)
- ⇒ минимум запретов на использование труда сообщества в личных целях (если это не вредит в перспективе)
- ⇒ распространение ПО — это не итог/цель, а средство вовлечения потенциальных коллег
Поддержка совместной разработки, в т. ч с большим количеством отложенного (offline) общения
- Дисциплина разработки
- DVCS
- Списки рассылки
- Система отслеживания ошибок
- Технологические ресурсы
Свободное лицензирование
Лицензия определяет:
Условия использования
- Если не противоречит УК, по российским законам можно всё)
Условия распространения
Правообладатель: тот, кто определяет условия распространения, имеет исключительные права на произведение
- Некоторые исключительные права неотторжимы от автора
Для роли распространителя достаточно передать ему неисключительные права
RMS и Свободное лицензирование
- Цель: защита открытой модели разработки
- От прямых угроз разработке
- От эксплуатации, приносящей ущерб (не от всякой, в целом эксплуатация — хорошо)
- От юридических казусов
- Задача: создать лицензионную базу, аналогичную той, что защищает закрытую модель разработки
Собственно, Определение_свободного_программного_обеспечения:
- Право на использование
- Право на изучение и модификацию
- Право на распространение
Право на распространение модифицированных версий
Обратите внимание:
Ничего не сказано про дисциплину изменений
Ничего не сказано про деньги, однако запрет коммерческого использования — это прямое нарушение свободной лицензии
Ничего не сказано про передачу исключительных прав (например, надо ли сохранять авторство? зависит от конкретной лицензии)
⇒ Ещё один пункт, т. н. Копилефт — сохранение свободности лицензии:
Лицензия, под которой распространяется производный продукт, должна соответствовать всем пяти пунктам исходной лицензии
Дистрибутивы, репозиотрии, пакеты и сообщество
Конспект лекции 2016 года (про дистрибутивы)
Предпосылки: свободное лицензирование и открытая разработка
можно создавать публичный сборник ПО (в т. ч. улучшенных версий), т. н. репозиторий, делать из него любые программные решения и т. д.
принимать участие может любой
Ресурсы сообщества:
- сборочные серверы
- элементы интеграционного тестирования, невозможные без центрального хранилища
- информационное пространство (отслеживание ошибок, wiki, соцсети, …)
- Репозиторий
«Дистрибутив ОС» — это
- Комплект пакетов (несколько тысяч)
- Гарантия совместимости: участие в репозитории
- (вполне возможно) Дополнительное тестирование/оформление
- Программа-установщик
- (вполне возможно) Решение каких-то коммерческих задач
Пакет
Целая лекция только про пакеты
- Комплект файлов (архив)
- Установка/удаление (регистрация/дерегистрация)
- Специфика файлов: конфигурационные, призраки и т. п.
- Установочные сценарии
- pre-/post-, -install/-config и пр.
- триггеры — общесистемные сценарии
- Установочные зависимости (на другой пакет, на файл, на «сущность»)
- Конфликты и альтернативы
- Установщик пакета
- Работает с отдельными пакетами
- установка / удаление (deb: переконфигурация) / обновление
- отслеживание зависимостей
- проверка целостности
- Пакетный диспетчер
- Работает с репозиториями
- доставка
- построение и обсчёт дерева зависимостей
- рекурсивная установка / удаление / обновление
- с учётом возможной разноверсицы
- по вторичным provides
- Сборщик пакетов
- Работает со спецификацией
- Разворачивает исходники
- «Проигрывает» процедуру сборки:
- Применяет патчи
- Запускает сборку
- Запускает установку в подкаталог
- Формирует бинарный пакет
- Не требует root!
Требует наличия сборочной среды
Репозиторий
Репозиторий — примерно такой же свободный проект, как и его компоненты.
- Редко требуется тиражирование механики самого репозитория
- Много стороннего кода (зачастую — всё, кроме спецификаций)
Пользователи репозтория — конструкторы дистрибутивов / внедрений / сервера на работе / просто начинки собственного компьютера
Задачи репозитория:
- Собственно, сборник (+доставка)
- Сборка на стороне репозитория
- Изолированная в чистом окружении
- Гарантия оформления в соответствии с дисциплиной
- Дополниетльные тесты при сборке
- Интеграционное тестирование
- Например, наличия зависимостей (т. е. отсутствия unmet-ов)
Например, работа с полной таблицей символов, предоставляемых всем репозиторием
- файловых конфликтов
- …
Роль майнтейнера вместо роли ключевого разработчика
- Взаимодействие с т. н. «апстримом» (авторами конкретного ПО)
- Адаптация к дисциплине сообщества и улучшение
Создание пакета
- Первоначальное тестирование
Требования к сборочной среде
- Изоляция
Не непосредственно в хост-системе
- Без влияния сборочной среды на хост-систему
- Воспроизводимость
- Не в окружении непонятно как и когда поставленных пакетов
Пример сборки пакета
Не успели. См. LecturesCMC/PackageMaintaining2013