Управление пакетами: Точка сборки
Прошло три недели с тех пор, как был опубликован предыдущий блогпост и некоторые читатели стали спрашивать о текущем состоянии проекта и чем сейчас занимаются Инго и Оливер. Разработчики сообщают, что сами планировали составить небольшой пост с обновлениями, так что все пришлось очень кстати. Они достигли одного из важнейших рубежей на пути к воплощению проекта: HaikuPorter поддерживает иерархическую сборку пакетов. Инго сообщает:
Получив название пакета, программа теперь анализирует дерево HaikuPorter, содержащее все инструкции для сборки, рекурсивно определяя какие еще пакеты требуются для успешной компиляции пакета и собирает все, что нужно в правильном порядке. Каждый пакет собирается в чистом chroot, это означает окружение, в котором устанавливаются только пакеты, требующиеся для сборки данного пакета в соответствии с инструкциями. Таким образом мы уменьшаем вероятность того, что собираемый нами пакет не будет запрашивать для себя других пакетов, которые ему в действительности нужны. Это позволит избежать ошибок и «поломок» после установки.
Я уже писал в предыдущем посте, что мы планировали в короткие сроки достичь этого рубежа. С незначительными исключениями мы и сегодня придерживаемся этого плана. HaikuPorter все еще написан на Python, однако, мы не обнаружили каких-то больших проблем с Python в окружении chroot. На данный момент у нас нет в наличии утилиты передачи файлов Gentoo-Portage EBuild в формат наших инструкций для сборки. По идее это хорошее решение, однако, количество пакетов, в которых мы сейчас заинтересованы (т.е. такие, которые нужны для сборки типового релиза Haiku) невелико (менее 50), так что возиться с Portage мы пока не будем.
Пока Оливер трудился над HaikuPorter и требуемыми изменениями в инструкциях для сборки, я в свою очередь работал над libsolv - библиотека была обновлена до последней версии, а ее порт для Haiku приведен в рабочее состояние. Имплементирована поддержка разрешения зависимостей в Package Kit, за исключением некоторых вещей, которые еще не доделаны, но близки к завершенному состоянию. Добавлена команда “resolve-dependencies” в нашу утилиту pkgman. Эта команда используется в HaikuPorter для разрешения зависимостей между пакетами и для определения того, что именно должно быть установлено в chroot для компиляции того или иного пакета.
За исключением исправления нескольких ошибок в PackageFS и BindFS, это по большей части все, что я должен был сделать на данном этапе нашего проекта, поэтому я переключился на другие дела. Самое главное - я начал работу над Package Daemon, компонентом будущей системы, который до сих пор отсутствовал. Этот компонент выполняет функции главной службы управления активированными пакетами. Он следит за директориями пакетов во всех местах для установки, активирует пакеты, перенесенные туда пользователем вручную и отключает удаляемые пакеты. Эта функциональность была прежде имплементирована в Package FS. В свою очередь Package Daemon будет проверять все необходимые зависимости новых пакетов и если надо предупреждать пользователя в том случае, когда появляются противоречия или должны быть установлены дополнительные пакеты. Как раз эта функциональность пока еще не была реализована, но при запуске службы она уже умеет проверять текущие активированные в системе наборы пакетов на целостность.
Служба Пакетов также отвечает за активацию и отключение пакетов, запрошенных программой управления пакетами (pkgman и будущим графическим пакет-менеджером) с помощью классов Package Kit. Над этим мы только-только начали работать. Далее занялся командой “install” в pkgman. Получив спосок названий пакетов для установки, он может разрешать зависимости из сконфигурированных репозиториев. На данный момент не хватает компонента для собственно скачивания файлов и запроса на их активацию в Службу Пакетов. Когда команда “install” будет готова, то с “remove” и “update” не будет значительных хлопот, поскольку хоть выходной результат и отличается, шаги для выполнения этой функции практически одинаковые (разрешение зависимостей, загрузка новых пакетов (если таковые имеются), сообщение Службе о том, что нужно активировать или отключить). Когда эти функции будут закончены, базовая реализация «выполняемого» в прямом эфире компонента нашей системы управления пакетами будет в рабочем состоянии. Это значит, что пользователь сможет управлять репозиториями приложений, устанавливать, удалять и обновлять пакеты.
Тем не менее, впереди еще достаточно много другой работы. Нашим следующим рубежом станет обновление пакетной ветки Haiku до самого свежего состояния кода Haiku. В данный момент наша ветка базируется на старом дереве исходников Haiku двухлетней давности! Поскольку с тех пор много портированного программного обеспечения было обновлено, для начала придется составить пакеты для этих новых версий, а те в свою очередь требуют от нас создания рабочих инструкций для сборки. В этом сейчас состоит задание Оливера.
Нашей целью в оставшееся от контракта время является доведение подсистемы управления пакетами Haiku до такой кондиции, при которой мы сможем экспортировать нашу ветку обратно в главное дерево Haiku. Мы совершенно точно не успеем завершить 100% всего, что будет полноценным менеджером пакетов за оставшееся время, однако мы предоставим базовую функциональность поверх уверенной системной базы для продолжения работы над управлением пакетами Haiku в штатном режиме. Мы надеемся, что другие разработчики Haiku не заставят себя долго ждать и помогут нам общими усилиями довести проект до полноценного состояния.
Итак, какую основную часть работы мы хотели бы завершить?
- По части сборки пакетов требуется реализовать еще несколько функций в HaikuPorter, например сборка большого количества пакетов из одной инструкции для сборки и компиляция целых репозиториев.
- Вся инфраструктура репозитория нуждается в пересмотре (мы только начали мозговой штурм этой проблемы), также поддержка утилитами.
- Поддержка гибридов GCC2/GCC4 нуждается в том, чтобы ее вернули в систему сборки. Ей придется работать иначе, чем ранее, поэтому два года назад мы убрали ее совсем, чтобы не мешалась. Также имеются некоторые проблемы с системой сборки, которые придется разрешить (например, установка MIME типов файлов перед упаковкой).
- Мы сделали несколько изменений формата пакетов в нашем TODO-листе. Было бы хорошо поработать над этим перед тем, как «выпускать пакетник в свет». С другой стороны, это можно сделать и позднее, но при этом проблемы сами не рассосутся и будут напоминать о себе в дальнейшем.
Инго Вейнхольд
Оригинал статьи