Cinnamon
Beelzebubbie 20 сентября, 2017 - 18:08
Решил поставить Cinnamon, споткнулся на том, что networkmanager – в зависимостях вне зависимости от соотв. флага. в «главном» пакете эта зависимость (хотя и с плюсом зачем-то в IUSE), но отключается. Однако в gnome-extra/cinnamon-control-center видим:
# FIXME: modemmanager is not optional
# networkmanager is not optional
COMMON_DEPEND="
…
>=net-misc/modemmanager-0.7
>=net-misc/networkmanager-0.9.8:=[modemmanager]вопрос в том, как это убрать БЕЗ того, чтобы нести в оверлей и переписывать ебилд каждый раз. на самом деле networkmanager таки optional, потому как в той же кальке при установке выбирается кто рулит сетями – нм или опенрц. Конечно, этот вопрос можно поднять в багзилле, но на него вряд ли ответят раньше, чем к нему потеряется интерес. Да, и разбираться пару часов как именно это сделано в кальке, не хотелось бы.
»
- Для комментирования войдите или зарегистрируйтесь
Все как раз с точностью до наоборот!
Если унесешь ебилд в оверлей и дашь ему номер версии выше, чем в репе, то ничего переписывать не надо будет - ебилд будет браться из оверлея, пока версия в репе не перерастет твою в оверлее.
по-моему, ты меня не понял совсем :-)
Цель то как раз в том, чтобы:
1. не нести ничего в оверлей, потому как де-факто нужно *только* заменить
>=net-misc/modemmanager-0.7 >=net-misc/networkmanager-0.9.8:=[modemmanager]на что-то вроде:
networkmanager? ( >=net-misc/modemmanager-0.7 >=net-misc/networkmanager-0.9.8:=[modemmanager] )конечно хз я что такое modemmanager но мне он нужен в равной степени с networkmanager, так что меня устроило бы в вышеуказанном виде.
и дашь ему номер версии выше, чем в репе, то …получится лютая ересь. потому как
1) возможны зависимости версий и версия 99999999999 просто не удовлетворит зависимостям
2) возможны изменения в ебилдах новых версий, которые будут успешно проигнорированы с малопредсказуемыми последствиями
в то время как «патчение» вышеуказанным способом, вероятно, ничего не сломает – пока весь ебилд не будет переписан с нуля, чего скорее всего еще с десяток лет не случится.
вопрос собственно – как такое «патчение» реализовать. явно что-то подобное есть, тщательно недодокументированное, как обычно.
Никто не заставляет тебя
Никто не заставляет тебя делать версию 99999999999, можешь просто добавить еще одно минорное число к номеру текущей версии или просто букву. И параллельно послать свою заплатку в багзиллу, может и достаточно быстро примут.
> добавить еще одно минорное
> добавить еще одно минорное число к номеру текущей версии
а когда выйдет новая версия главного пакета. и новая версия этого контрол-центра? предлагаешь забивать пока не начнутся странные косяки?
я веду к тому, как сделать *один*раз*.
>>может и достаточно быстро примут
на текущую дату «быстро» означает «не позже следующего года». что, я в багзилле не бывал?
Даже сам ебилд взывает к его
Даже сам ебилд взывает к его починке. Хотя возможно что для такой ситуации есть причины...
кстати а где описано что
кстати а где описано что можно и что нельзя делать в bashrc files in /etc/portage/env/ ?
Может тут?
Может тут?
Usefulness of bashrc
Сам не проверял, но надеюсь, что Генту еще следует завещанию отца-основателя! :)
тут даже меньше чем ничего в
тут даже меньше чем
ничегов man portage :-)полезного чутка тут, а тут про фазы, однако все это лоскуты. Говорится, что якобы можно вмешаться в любое время в ебилдные процессы, но это беллетристика. Непонятно какими переменными и когда можно/неможно управлять ну и так далее
Просто я полагал, что ты
Просто я полагал, что ты ищешь не готовый рецептов, а концепцию.
Похоже, что я ошибся.
меня как раз таки концепция и
меня как раз таки концепция и интересует. из которой явным и однозначным способом можно вывести решение исходного вопроса. но пока я нашел несколько частностей плюс нечто вроде идеологии.
так где же она, …
…концепция? :-)
/
Официальных док по данному вопросу мне не известно.
Популярное описание — у мегабакса. Вопрос: по каким докам оно собрано (и всё ли извлекается из документации, без обращения к исходникам) — заслуживает отдельного исследования. И с точки зрения логики на момент написания описание не вполне совершенно, известен как минимум один баг.
Применительно к твоему вопросу прогноз пессимистичный:
:wq
--
Live free or die
переопределение вышеописанных
переопределение вышеописанных ф-ий не обеспечивает результата «вмешиваться в процесс emerge на каждом шаге его выполнения». по крайней мере ни одна из них не вызывается на этапе расчета зависимостей при emerge -a some_package (проверено электроникой).
из чего следует, что таким образом изменить *DEPEND не должно получится. однако весьма вероятно, что данный список функций просто далеко не полон.
.
Полагаю, дело в том, что есть
ebuild:И есть
emerge:И в том, что на низком уровне отрабатываются не все этапы алгоритма.
ЗЫ: И ещё: для читаемости в исторической перспективе было бы нелишним приложить информацию [хотя бы] о версии
portage.:wq
--
Live free or die