История изменений

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

Я гентой не пользуюсь, но подозреваю, что у ebuild'ов могут быть несколько иные задачи, чем у скриптов autoconf. Autoconf предназначен для определения зависимостей, причём достаточно гибко (их можно определять по названию зависимости, её версии, а также по наличию/отсутствию отдельных файлов и идентификаторов), причём определяются как сборочные, так и run-time зависимости. Затем идёт собственно процесс сборки с теми или иными опциями и инсталляция.

Пакеты же (и, полагаю, отчасти ebuild'ы) должны не просто определять, удовлетворены ли зависимости или нет, но и разрешать их, для чего необходимо указывать, откуда эти зависимости можно скачать. С другой стороны, уже не предполагается, что зависимость установлена (а если нет, то сначала установите руками, а потом снова запускайте configure), а предполагается лишь, что она либо установлена, либо может быть автоматически установлена, и этого достаточно. Соответственно, метод проверки на основе существования какого-то идентификатора, как в случае с automake, уже не подходит (хотя этот метод более гибкий). Т. е. если меня, как разработчика, интересует наличие какой-то функции, то я могу проверить это с помощью autoconf, не завязываясь на версии библиотек, а проверяя именно наличие функции. Этот метод в общем случае гибче (мне не надо думать, в какой версии впервые появилась эта функция, и выбросят ли её в будущих версиях, я просто проверяю, есть она или нет). Но майнтейнер, имея дело с ещё не установленной зависимостью, не может на это полагаться. Он должен сначала её установить, но до этого выяснить, подходит ли данная версия. Соответственно, ориентироваться он может только на номера версий.

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

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

Я гентой не пользуюсь, но подозреваю, что у ebuild'ов могут быть несколько иные задачи, чем у скриптов autoconf. Autoconf предназначен для определения зависимостей, причём достаточно гибко (их можно определять по названию зависимости, её версии, а так же по наличию/отсутствию отдельных файлов и идентификаторов), причём определяются как сборочные, так и run-time зависимости. Затем идёт собственно процесс сборки с теми или иными опциями и инсталляция.

Пакеты же (и, полагаю, отчасти ebuild'ы) должны не просто определять, удовлетворены ли зависимости или нет, но и разрешать их, для чего необходимо указывать, откуда эти зависимости можно скачать. С другой стороны, уже не предполагается, что зависимость установлена (а если нет, то сначала установите руками, а потом снова запускайте configure), а предполагается лишь, что она либо установлена, либо может быть автоматически установлена, и этого достаточно. Соответственно, метод проверки на основе существования какого-то идентификатора, как в случае с automake, уже не подходит (хотя этот метод более гибкий). Т. е. если меня, как разработчика, интересует наличие какой-то функции, то я могу проверить это с помощью autoconf, не завязываясь на версии библиотек, а проверяя именно наличие функции. Этот метод в общем случае гибче (мне не надо думать, в какой версии впервые появилась эта функция, и выбросят ли её в будущих версиях, я просто проверяю, есть она или нет). Но майнтейнер, имея дело с ещё не установленной зависимостью, не может на это полагаться. Он должен сначала её установить, но до этого выяснить, подходит ли данная версия. Соответственно, ориентироваться он может только на номера версий.

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