Автоматический патч ебилда

Делаешь свою ревизию в локальной репе и всё.

Неудобно, когда в апстриме патч обновляется. По-хорошему, надо делать форк gentoo/gentoo, в нём свою ветку, и периодически её ребейзить на мастер.

Какой патч? Он хочет платить ebuild. Проблема патчей вообще в том, что они могут не применяться из-за слишком сильных отличий.

Зачем ему ради пары ebuild держать целую ветку?

В его локальную ветку и так никто не влезет, а ребейз ему не поможет обновить свои ebuild до новых версий автоматически, с наложением патчей на сами ebuild’ы.

Делаешь свою ревизию в локальной репе и всё

И какая разница, локальная репа или официальная? Всё равно надо обновлять ебилд, а где он лежит в /var/db/repos/gentoo или /var/db/repos/local совершенно без разницы.

Это прокатило бы, если один раз пропатчил и затем не обновляешь пакет. Но обновлять нужно

Пока вижу только костыль - после emerge --sync запускать скрипт (не патч, ибо патч может не сработать при изменениях в ебилде), который ищет паттерн в ебилде и вырезает его.

Но может есть какой-то бескостыльный способ?

Есть ли какой-нибудь способ автоматического применения патча не к сорцам, а к ебилду?

А чего ты хочешь этим достичь?

Может тебе хуков хватит?

Хук может убрать зависимости?

Ненужные зависимости складываются в package.provided

package.provided тоже требует постоянно ручного вмешательства, как минимум править версии пакетов.

патч тоже придётся обновлять.

package.provided тоже требует постоянно ручного вмешательства, как минимум править версии пакетов.

category/package-10000, не?

а ребейз ему не поможет обновить свои ebuild до новых версий автоматически, с наложением патчей на сами ebuild’ы

Поможет

Проблема патчей вообще в том, что они могут не применяться из-за слишком сильных отличий.

git частично решает эту проблему, так как при ребейзе видит историю изменений. А если конфликты не решатся автоматически, то можно «дорешать» оставшиеся ёлочки вручную.

Не надо трогать официальное дерево, пусть остаётся а том виде, какое оно есть.

Так ему не хочется по возможности поправить в ручную.

category/package-10000, не?

Странно, но 10000 вместо версии работает. Что за магическое число такое - 10000?

git rebase автоматизирует процесс адаптации патча к изменениям настолько, насколько это доступно человеческим технологиям на сегодняшний день:)

Можно ещё git rerere включить, чтобы учитывать предыдущий опыт разрешения конфликтов.

никакой магии нет - в package.provided ты кладешь atom(category/package-version) и emerge воспринимает это, как будто он у тебя безальтернативно установлен.

Но если ты положишь туда например category/package-1.0, а потом когда-нибудь выйдет package-1.1 - emerge предложит его «обновить»

Вариант - указать максимально возможную версию, которой никогда не будет у пакета. Т.к. live ebuild-ы в Gentoo имеют версию 9999, то достаточно указать 10000.

Правда я уже видел пару исключений в дереве, но это в основном служебные пакеты

Т.е. 10000 включает все версии, следующие за live, своего рода wildchar?

Это просто достаточно большое число, соответствующее формату версии пакета из Package Manager Specification. Если где-то будет выпущена версия 10001 для какого-то пакета - он попытается «обновиться».

Так можно и 39156.999 и 64723.2.0 указать - никто не запрещает.

Ясно, спасибо

Как всегда, в Gentoo всё просто оказывается :)

Git rebase сделает что-то отличное от ого, что сделала бы команда patch?

Да. Вполне обычна ситуация, когда patch бессилен, а git rebase автоматически накладывает изменения без вмешательства пользователя.

Проше просто подождать пропатченные ебилды.