25 сентября произошёл один из важнейших за последние годы прорывов в развитии Gentoo: Gentoo Council принял новый EAPI. Что это значит? Если коротко, то это означает обновление формата ебилдов, и, соответственно, добавление новых возможностей в менеджер пакетов.

Достаточно сказать, что запрос о возможности указывать для зависимостей USE-флаги датирован 2002 годом, и всё это время использовалось обходное решение, которое стоило пользователям немало потерянного времени.

Подробнее о EAPI 2, и о том, как он появился описано в этой статье. Полная поддержка EAPI 2 реализована в Portage 2.2, релиз-кандидаты которого пока что находятся в тестовой ветке.

Также ещё одним важным нововведением Portage 2.2 являются sets (наборы? коллекции?). Вот в этой статье я вкратце описал, что даёт это нововведение, и как оно в частности повлияло на релиз пакетов KDE 4. Дополнительную информацию о наборах можно почерпнуть из записи в блоге alexxy

Источник: http://gentoo.ru/node/12072
------------

Gentoo Linux: EAPI 2
25 сентября произошёл один из важнейших за последние годы прорывов в развитии Gentoo: принят новый EAPI. Что это значит? Если коротко, то это означает обновление формата ебилдов, и, соответственно, добавление новых возможностей в менеджер пакетов. Последние несколько лет Portage стагнировал, но развитие альтернативного менеджера пакетов Paludis, а также энтузиазм разработчиков Exherbo подтолкнул разработчиков Gentoo предпринимать шаги по развитию своего основного пакетного менеджера.

Итак, что такое EAPI? EAPI — это стандарт пакетного менеджера Gentoo, или же с другой стороны — стандарт написания ebuild’ов. В то время, как существовал всего один пакетный менеджер, необходимости в таком стандарте не было. Но когда одновременное существование Portage, Paludis, pkgcore, да ещё и Entropy игнорировать стало невозможно, да к тому же развитие некоторых из них обогнало Portage, то текущий статус-кво на тот момент был зафиксирован в виде стандарта, который назвали EAPI 0, и начали работать над его новыми версиями

EAPI 1 имеет немного отличий от EAPI 0. На пример, именно после реализации поддержки EAPI 1 стало возможным писать emerge kde-meta:3 или emerge kde-meta:4.

Весной появился новый EAPI, поддержка которого была реализована только в Paludis. Собственно, в этом EAPI были зафиксированы некоторые дополнительные возможности, которые уже были реализованные в Paludis, и которые хотели использовать разработчики оверлея genkdesvn. В упомянутом оверлее этот EAPI, получивший название kdebuild-1, и используется (с EAPI 2 он несовместим).

С появлением проекта Exherbo появился и новый EAPI под названием exheres-0. Это — рабочая версия EAPI Exherbo. Когда разработчики Exherbo примут решение, что этот EAPI их устраивает, то он будет зафиксирован в виде exheres-1, а exheres-0 так и останется постоянно изменяемым EAPI. Следующие “стабильные” EAPI будут называться exheres-2, exheres-3 и т.д. Фиксирование exheres-1 планируется сделать перед самым выходом первой публичной версии дистрибутива. Единственным пакетным менеджером, который используется в Exherbo является Paludis. Подробнее об exheres можно почитать здесь

Наконец, наш сегодняшний герой дня EAPI 2 был официально принят на заседании Gentoo Council 25 сентября, о чём объявлено в недавнем GMN, и некоторые оверлеи уже начали переходить на его использование. Paludis в полной мере поддерживает EAPI 2 с версии 0.30.1, а Portage — с версии 2.2_rc11. Поскольку ветка Portage 2.2 всё ещё является нестабильной, официальное дерево портежей по-прежнему является царством EAPI 1.

Итак, что же интересного подготовил нам EAPI 2? Собственно, изменения я пересказываю по серии записей в блоге разработчика Paludis’а, отсюда и внимание к взаимному влиянию EAPI друг на друга.

Пожалуй, самой долго ожидаемой фичей являются USE-зависимости. Очень долго ожидаемой.

До сегодняшнего дня если для компиляции одного пакета требовалось, чтобы другой пакет был установлен с определённым набором флагов, то это условие проверялось только перед самой компиляцией. То есть узнать о необходимости переустановить некоторый пакет вы могли не сразу после просчёта зависимостей, а через только часик-другой, когда Portage вылетит с ошибкой на 38-м пакете из 163. А если на 32-м пакете вы ушли спать, то утро будет омрачено. При чём вы не застрахованы от того, что подобная ошибка повторится ещё и на 65-м, 74-м, 109-м и 133-м пакетах. Неудивительно, что команда genkdesvn первой плюнула и отказалась от пакетного менеджера без USE-зависимостей перед тем, как сделать доступными разделённые ебилды для KDE 4: пакетов там много, и USE-зависимости играют важную роль.

USE-зависимости были включены и в kdebuild-1, и в exheres-0, но синтаксис их указания в EAPI 2 отличается:

[opt]
Флаг должен быть включён
[opt=]
Если флаг включён у устанавливаемого пакета, то он же должен быть включён у пакета, установленого по зависимости, выключен в противном случае
[!opt=]
Если флаг включён у устанавливаемого пакета, то он должен быть выключен у пакета, установленого по зависимости, включен в противном случае
[opt?]
Если флаг включён у устанавливаемого пакета, то он же должен быть включён у пакета, установленого по зависимости
[!opt?]
Если флаг включён у устанавливаемого пакета, то он должен быть выключён у пакета, установленого по зависимости
[-opt]
Флаг должен быть выключен

Примеры указания USE-зависимостей:

foo/bar[!baz]
foo/bar[baz,monkey?]
foo/bar:1[baz]
>=foo/bar-2.1:2[baz]

Важно: пакетный менеджер не должен предлагать «автомагически» переустанавливать пакет foo/bar с нужным набором USE-флагов. Вы сами должны решить, хотите ли вы изменить конфигурацию этого пакета в make.conf или /etc/portage/package.use (или use.conf в случае Paludis’а).

Следующим пунктом нашей программы являются так называемые SRC_URI Arrows. По сути это возможность обойти некорректные названия тарболлов с исходниками. Если upstream-автор некоторого пакета не включает в название файла с тарболлом уникальное название пакета и номер версии, то при загрузке архива из сети может возникнуть конфликт из-за того, что distfiles является «плоским» каталогом, и название загружаемого файла может совпадать с названием какого-либо файла, уже присутствующего в этом каталоге. Чтобы это обойти, вы можете указать в ебилде, как необходимо переименовать загружаемый файл. Примерно так:

SRC_URI="http://example.com/dir/1.23/stupid.tar.bz2 -> stupid-1.23.tar.bz2"

Или даже так:

SRC_URI="http://example.com/dir/${PV}/${PN}.tar.bz2 -> ${P}.tar.bz2"

Интересный момент: на сайте разработчика архив будет лежать под именем stupid.tar.bz2, а на distfiles.gentoo.org — под именем stupid-1.23.tar.bz2, и у Portage даже не слетит крыша по этому поводу :) Между делом решается и проблема загрузки архивов из gitweb, который имеет привычку дописывать ;sf=tbz2 или ;sf=tgz в конце ссылок. Эта возможность с самого начала входила и в kdebuild-1, и в exheres-0.

Ещё одним нововведением являются !!-блокировки. Их появление связано с тем, что в последнее время в Portage пытаются реализовать некоторое автоматическое разрешение блокировок, когда блокирующий пакет удаляется из системы после этапа компиляции. В некоторых случаях это ведёт к неприятным последствиям, поэтому и ввели дополнительный синтаксис для «да, я действительно это имею в виду»-блокировки.

Таким образом: - при !-блокировке Portage может попытаться автоматически удалить блокирующий пакет; - при !!-блокировке Portage отправит вас самостоятельно разбираться с конфликтующими сторонами, то есть пакетами.

В Exherbo используется более развитая система, в которой разработчик ебилда может указать различные варианты поведения при блокировках. При этом пользователю даётся чёткое описание всех действий, которые будет выполнять менеджер пакетов, и даже даётся ссылка на веб-страницу с объяснением природы конфликта между данными конкретными пакетами.

Следующий ряд изменений немного упрощает написание ебилдов: фаза src_unpack разделяется на src_unpack и src_prepare, а фаза src_compile — на src_configure и src_compile. Это даёт возможность более гибко управлять процессом сборки, и при этом более полно использовать дефолтные реализации фаз (до этого во многих случаях автору ебилда приходилось копи-пастить половину дефолтной реализации, чтобы внести необходимые изменения).

Фаза src_prepare вызывается после src_unpack, и её следует использовать для применения патчей. Таким образом, больше нет необходимости копи-пастить дефолтное определение src_unpack ради необходимости наложить определённые патчи.

Фаза src_configure вызывается перед src_compile. Кроме того, в EAPI 2 изменена дефолтная реализация src_compile.

И к слову о копи-пасте — были также добавлены функции default_<название фазы> для каждой фазы, а кроме того теперь можно в любой фазе вызвать функцию default.

Этот блок изменений пришёл в EAPI 2 прямиком из exheres-0 (за исключением некоторых деталей реализации). Для kdebuild-1 подобные нововведения рассматривались, но не были добавлены, поскольку их эффективному использованию мешала необходимость адаптировать eclass’ы, а оверлей должен был использовать eclass’ы из официального дерева.

И последней в этом списке является более корректная поддержка локалей директивой doman, в которой определяются man-страницы, предоставляемые пакетом. Portage далее сам разбирается, что с ними делать. Теперь достаточно указать что-то вроде

doman foo.1 foo.en.1 foo.en_GB.1 foo.es.1 foo.fr.1

…и соответствующие установленным в системе локалям man-страницы будут установлены «автомагически».

Данное изменение первыми реализовали разработчики Gentoo (см. соответствующий запрос в Багзилле), а разработчики Exherbo не преминули его позаимствовать.

Добавка: ещё одно нововведение в Portage 2.2 — наборы. См. мой обзор здесь

Источник: http://lxj.endofinternet.net/column/gentoo-linux-eapi-2/
------------

Маленькое дополнение к новости
Скоро выйдет portage-2.2. Хотя все желающие уже могут оценить релиз кандидаты =) Я например пользуюсь rc6 сейчас. Из основных и полезных фич добавили наборы поддержку EAPI=1 и EAPI=2_pre1 ( к релизу будет EAPI=2 в rc6 та всерсия что написана выше )
Из наборов в текущей весрсии есть следующие

* @system
* @world
* @installed
* @downgrade
* @preserved-rebuild
* @live-rebuild
* @module-rebuild
* @security

Как видите наборов стало больше а не только два world & system =) появились наборы которые включают все @installed. Набор который включает все пакеты версии которых ниже чем максимально возможные для данного профайла @downgrade.

Несколько системных наборов типа @preserved-rebuild ( он работает только если стоит FEATURES="preserve-libs" ) и позволяет пересобрать все пакеты зависящие от либ в которых весрсия либы изменилась или изменилась ABI
Наборы @live-rebuild и @module-rebuild используются соответственно для того что бы пересобрать все "живые" паекты и все внешние модули ядра. те они заменяют утилиты rep-rebuild и module-rebuild =)

Ну и на закуску самыйважный набор для админов @security он включает все пакеты которые вошли в GLSA

Источник: http://www.gentoo.ru/node/11462

------------
От себя. Круто :), приду домой будут тестировать.