Необходимость пересборки других пакетов

Возникла такая ситуация. В AUR есть пакет (мой) openbox_eui, который базируется на нынешнем состоянии git openbox (который уже помечен версией 3.6). При его установке (вместо официального openbox 3.5.2) устанавливается несколько библиотек, после чего начинают падать obconf и lxappearance-obconf из реп. Чтобы восстановить их работоспособность, достаточно их пересобрать из abs после после установки openbox 3.6. Соответственно, если обратно установить openbox 3.5 из реп, то и obconf с lxappearance-obconf надо тоже переустановить из реп.

Так вот, вопрос: можно ли (и как) отразить такую зависимость в PKGBUILD? Я не придумал ничего умнее, чем выдача предупреждения в install.
Как вариант - добавить в АУР пакеты obconf_eui и lxappearance-obconf_eui, и указать их в качестве необязательных зависимостей.
vadik
Как вариант - добавить в АУР пакеты obconf_eui и lxappearance-obconf_eui, и указать их в качестве необязательных зависимостей.
Не понравилось. По-первых, это не полное решение - отсюда никак не видно, что в случае сноса openbox_eui надо и их заменить на версии из реп. Во-вторых, это странное решение, поскольку эти исходные пакеты вообще ничем не отличаются от реповских, просто их надо собрать в другом окружении. Тут дело не в пакете, а в пересборке, так что лучше уж просто словами сказать при установке что надо пересобрать и зачем.
Кстати. А есть в Арч стандартный способ пересобрать определённый пакет из реп без установки всего abs?
Так-то есть yaourt -Sb 'pakage', но не знаю, будет ли работать без локальной базы, создаваемой abs. Не проверял никогда.

PS. Глянь ещё archlinuxfr/customizepkg, aur/customizepkg - может пригодится, хотя, не факт, что это вообще по твоему поводу, просто на всякий случай.

http://blog.cwill.us/2013/02/customizing-arch-packages-with.html - на русском не нашёл что-то...
bobart
Так-то есть yaourt -Sb 'pakage', но не знаю, будет ли работать без локальной базы, создаваемой abs. Не проверял никогда.
Проверил - работает. Сам скачивает всю базу :)
bobart
PS. Глянь ещё archlinuxfr/customizepkg, aur/customizepkg - может пригодится, хотя, не факт, что это вообще по твоему поводу,
Угу. Это про автоматизацию внесения своих изменений в PKGBUILD, а мне ничего менят не надо.

Похоже, ничего, кроме выдачи текста в install, таки нет. Спасибо ответившим.
akorop
Не понравилось. По-первых, это не полное решение - отсюда никак не видно, что в случае сноса openbox_eui надо и их заменить на версии из реп.
Ну правильно, так и должно быть. С точки зрения ОС это будут другие пакеты. Можно добавить их в конфликтующие и тогда с установкой пакета *_eui - будет удаляться (с запросом) пакет из репозитория.

akorop
Во-вторых, это странное решение, поскольку эти исходные пакеты вообще ничем не отличаются от реповских, просто их надо собрать в другом окружении.
Раз пакеты собраны в другом окружении, значит они отличаются от стандартного пакета. И это значит, что есть смысл дать этим пакетам другие названия, как раз, чтоб небыло путаницы и у конечного пользователя все работало как надо. То, что пакеты имеют один и тот же PKGBUILD не делает их одинаковыми.

Впрочем вы автор пакета и вам решать как вам удобнее.
vadik
Как вариант - добавить в АУР пакеты obconf_eui и lxappearance-obconf_eui
До меня только дошло.., вобщем, думаю, vadik дело говорит. Я бы так и сделал.

...Можно добавить их в конфликтующие и тогда с установкой пакета *_eui - будет удаляться (с запросом) пакет из репозитория.
И можно ещё добавить openbox_eui в кач-ве обязательной зависимости для obconf_eui и lxappearance-obconf_eui, чтобы и удалялись вместе с первым.
К сожалению, все эти костыли не только решают проблемы, но и создают. Например, если
bobart
добавить openbox_eui в кач-ве обязательной зависимости для obconf_eui
то юзер, который поставил "на попробовать" openbox_eui и затем вернувшийся к openbox из реп, получит неожиданный побочный эффект: снос obconf. Так что по-любому без пояснений не обойтись.
Если текущая сборка пакета требует, допустим, версии openbox 3.5.*, то в его параметрах должно быть примерно так:
depends=("openbox>=3.5" "openbox<3.6")
тогда при попытке обновления openbox БЕЗ обновления этого пакета, будет выдана ошибка: пакет требует другую версию openbox.
Natrio
огда при попытке обновления openbox БЕЗ обновления этого пакета, будет выдана ошибка: пакет требует другую версию openbox.
Спасибо за подсказку, это могло бы корректно решить проблему, но, к сожалению, в реповских PKGBUILD для *obconf такого нет, там просто "openbox".
 
Зарегистрироваться или войдите чтобы оставить сообщение.