#11
|
|||
|
|||
Чем сейчас мод(ж)но смотреть полное дерево зависимостей порта?
Sergey Anohin написал(а) к Victor Sudakov в Dec 18 12:30:58 по местному времени:
Нello, Victor! SA>> не то? SA>> https://forums.freebsd.org/threads/h...ency-tree.2190 SA>> / VS> Не то. Во-первых, речь шла о пакетах, а не дереве портов. Но это можно было бы потерпеть. VS> Во-вторых и главных, просили дерево зависимостей, а не линейный список зависимостей данного порта. Т.е. хотелось выяснить, какая непрямая зависимость данного пакета вдруг требует пакета X в качестве своей зависимости. Часто ведь есть скромный список из нескольких прямых зависимостей, а на поверку их оказывается огромная гора непрямых. VS> Можеть быть pkg_depends.pl из твоей второй ссылки подойдет, я попробую. Но странно что такого инструмента нет в портах. ну как? рабочее? С наилучшими пожеланиями, Sergey Anohin. --- wfido |
#12
|
|||
|
|||
Чем сейчас мод(ж)но смотреть полное дерево зависимостей порта?
Dmitry Kolvakh написал(а) к Eugene Grosbein в Dec 18 15:12:30 по местному времени:
Нi Eugene! 29 Dec 18, Eugene Grosbein wrote to Dmitry Kolvakh: EG> Ты спрашивал не про полное дерево, ты изначально задал совершенно EG> другой вопрос, для ответа на который полное дерево и не нужно, EG> и даже не поможет в некоторых случаях, так как оно покажет EG> только run-зависимости, а docbook вполне мог быть build-зависимостью, EG> если ты собирал из портов, а не ставил пакетами. Собирал из портов. EG> Тебе что на самом деле-то надо узнать? Узкий локальный вопрос - где снять галочку, чтобы при сборке open-vm-tools-nox11 не собирался docbook с кучей библиотек для xml. И широкий глобальный - именно посмотреть на полное дерево зависимостей, что в принципе интересно для оценки, сколько чего какой порт может потянуть за собой. Чтоб узнавать это не в процессе установки. Понятно, что при разных опциях сборки число реально поставленных зависимостей будет разное, но хоть видны заранее потенциальные грабли. -- Good Luck! - Dmitry V. Kolvakh aka Keu --- GoldED+/W32-MINGW 1.1.5-b20060703 |
#13
|
|||
|
|||
Чем сейчас мод(ж)но смотреть полное дерево зависимостей порта?
Victor Sudakov написал(а) к eugen в Dec 18 17:30:46 по местному времени:
Dear eugen, 29 Dec 18 07:19, Eugene Grosbein wrote to Dmitry Kolvakh: EG>>> pkg info -rx docbook EG>>> Или наоборот, pkg info -dx open-vm-tools DK>> Так вот полного дерева оно не выдает, только зависимости первого DK>> порядка: EG> Ты спрашивал не про полное дерево, ты изначально задал совершенно EG> другой вопрос, для ответа на который полное дерево и не нужно, EG> и даже не поможет в некоторых случаях, так как оно покажет EG> только run-зависимости, а docbook вполне мог быть build-зависимостью, EG> если ты собирал из портов, а не ставил пакетами. Всё Дмитрий правильно спрашивал, по крайней мере я прекрасно понял его вопрос. EG> Тебе что на самом деле-то надо узнать? "Хочется посмотреть, кто же из зависимостей для open-vm-tools-nox11 вдруг потащил за собой docbook и кучку связанного с ним дерьма." Victor Sudakov, VAS4-RIPE, VAS47-RIPN --- GoldED+/BSD 1.1.5-b20160322-b20160322 |
#14
|
|||
|
|||
Чем сейчас мод(ж)но смотреть полное дерево зависимостей порта?
Victor Sudakov написал(а) к eugen в Dec 18 17:33:40 по местному времени:
Dear eugen, 29 Dec 18 11:05, Eugene Grosbein wrote to me: VS>> Во-вторых и главных, просили дерево зависимостей, а не линейный VS>> список зависимостей данного порта. Т.е. хотелось выяснить, какая VS>> непрямая зависимость данного пакета вдруг требует пакета X в VS>> качестве своей зависимости. Часто ведь есть скромный список из VS>> нескольких прямых зависимостей, а на поверку их оказывается VS>> огромная гора непрямых. EG> Искать глазками в огромном дереве зависимостей - плохой способ, EG> поэтому рисовать дерево зависимостей и избыточно, и не поможет. Если вывести в graphwiz, вообще круто будет. EG> Правильная формулировка задачи - половина решения. EG> Если на самом деле нужен путь по дереву зависимостей, EG> начинающийся с одного заданного порта и заканчивающийся на другом EG> заданном, Задача такая, простой пример: ставишь (pkg install) некую консольную утилиту и удивлённо видишь, что она потащила за собой xlib с кучей причиндалов. При этом самой утилите иксы точно не нужны. Хочется узнать, какая из непрямых зависимостей подхватила иксы. EG> то это вовсе не рисование дерева, а как раз таки линейный EG> список и он делается довольно несложно: Сейчас потестируем. Victor Sudakov, VAS4-RIPE, VAS47-RIPN --- GoldED+/BSD 1.1.5-b20160322-b20160322 |
#15
|
|||
|
|||
Re: Чем сейчас мод(ж)но смотреть полное дерево зависимостей порта?
Eugene Grosbein написал(а) к Dmitry Kolvakh в Dec 18 20:30:54 по местному времени:
29 дек. 2018, суббота, в 15:12 NOVT, Dmitry Kolvakh написал(а): EG>> Ты спрашивал не про полное дерево, ты изначально задал совершенно EG>> другой вопрос, для ответа на который полное дерево и не нужно, EG>> и даже не поможет в некоторых случаях, так как оно покажет EG>> только run-зависимости, а docbook вполне мог быть build-зависимостью, EG>> если ты собирал из портов, а не ставил пакетами. DK> Собирал из портов. Соответственно, man ports Там это документировано. EG>> Тебе что на самом деле-то надо узнать? DK> Узкий локальный вопрос - где снять галочку, чтобы при сборке DK> open-vm-tools-nox11 не собирался docbook с кучей библиотек для xml. Оно не тянет за собой docbook. Только что проверил - собрал и поставил его на машине без каких-либо портов docbook и после установки они не появились. DK> И широкий глобальный - именно посмотреть на полное дерево зависимостей, что в DK> принципе интересно для оценки, сколько чего какой порт может потянуть за собой. DK> Чтоб узнавать это не в процессе установки. cd /usr/ports make fetchindex cd /usr/ports/... make pretty-print-run-depends-list make pretty-print-build-depends-list Это всё из man ports Eugene -- Поэты - страшные люди. У них все святое. --- slrn/1.0.3 (FreeBSD) |
#16
|
|||
|
|||
open-vm-tools
Eugene Grosbein написал(а) к Dmitry Kolvakh в Dec 18 20:36:29 по местному времени:
29 дек. 2018, суббота, в 15:12 NOVT, Dmitry Kolvakh написал(а): EG>> Ты спрашивал не про полное дерево, ты изначально задал совершенно EG>> другой вопрос, для ответа на который полное дерево и не нужно, EG>> и даже не поможет в некоторых случаях, так как оно покажет EG>> только run-зависимости, а docbook вполне мог быть build-зависимостью, EG>> если ты собирал из портов, а не ставил пакетами. DK> Собирал из портов. И да: open-vm-tools на самом деле не нужен, если только у тебя не жесточайший highload в виртуалках. Можно, наверное, включить vmwareguest_vmblockenable="YES", vmwareguest_vmhgfs_enable="YES", vmware_guest_vmmemctlenable="YES" и vmwareguestd_enable="YES", а вот включать vmware_guest_vmxnetenable я бы не рекомендовал: порт содержит древнючую версию драйвера vmxnet, а в базовой системе уже есть vmxnet3 и гораздо свежее и функциональнее. Может, и остальные части в базе есть - не разбирался, но точно знаю, что FreeBSD в качестве гостя vmware нормально живёт вообще без open-vm-tools (спроси меня, откуда я это знаю). Eugene -- Choose no career --- slrn/1.0.3 (FreeBSD) |
#17
|
|||
|
|||
Re: Чем сейчас мод(ж)но смотреть полное дерево зависимостей порта?
Eugene Grosbein написал(а) к Victor Sudakov в Dec 18 20:37:30 по местному времени:
29 дек. 2018, суббота, в 17:30 NOVT, Victor Sudakov написал(а): EG>>>> pkg info -rx docbook EG>>>> Или наоборот, pkg info -dx open-vm-tools DK>>> Так вот полного дерева оно не выдает, только зависимости первого DK>>> порядка: EG>> Ты спрашивал не про полное дерево, ты изначально задал совершенно EG>> другой вопрос, для ответа на который полное дерево и не нужно, EG>> и даже не поможет в некоторых случаях, так как оно покажет EG>> только run-зависимости, а docbook вполне мог быть build-зависимостью, EG>> если ты собирал из портов, а не ставил пакетами. VS> Всё Дмитрий правильно спрашивал, по крайней мере я прекрасно понял его вопрос. К сожалению, вопрос был классическим примером "проблемы XY" - дерево тут не причём. EG>> Тебе что на самом деле-то надо узнать? VS> "Хочется посмотреть, кто же из зависимостей для open-vm-tools-nox11 вдруг VS> потащил за собой docbook и кучку связанного с ним дерьма." Никто. Eugene --- slrn/1.0.3 (FreeBSD) |
#18
|
|||
|
|||
Re: Чем сейчас мод(ж)но смотреть полное дерево зависимостей порта?
Eugene Grosbein написал(а) к Victor Sudakov в Dec 18 20:41:07 по местному времени:
29 дек. 2018, суббота, в 17:33 NOVT, Victor Sudakov написал(а): EG>> Искать глазками в огромном дереве зависимостей - плохой способ, EG>> поэтому рисовать дерево зависимостей и избыточно, и не поможет. VS> Если вывести в graphwiz, вообще круто будет. В огромном дереве неудобно глазками искать и в графическом виде тоже. EG>> Правильная формулировка задачи - половина решения. EG>> Если на самом деле нужен путь по дереву зависимостей, EG>> начинающийся с одного заданного порта и заканчивающийся на другом EG>> заданном, VS> Задача такая, простой пример: ставишь (pkg install) некую консольную утилиту и VS> удивлённо видишь, что она потащила за собой xlib с кучей причиндалов. При этом VS> самой утилите иксы точно не нужны. Хочется узнать, какая из непрямых VS> зависимостей подхватила иксы. Ты будешь смеяться, но это совершенно другая задача, ибо в этой формулировке вопрос про копание в репозитории (pkg search) ещё не установленных пакетов, а вовсе не про разборки с установленными пакетами (pkg query/info) после установки из портов. Eugene --- slrn/1.0.3 (FreeBSD) |
#19
|
|||
|
|||
open-vm-tools
Dmitry Kolvakh написал(а) к Eugene Grosbein в Dec 18 20:07:27 по местному времени:
Нello, Eugene Grosbein. On 29.12.18 20:36 you wrote: EG> И да: open-vm-tools на самом деле не нужен, если только у тебя не EG> жесточайший highload в виртуалках. Нужен для корректного выключения виртуалки извне EG> Можно, наверное, включить vmwareguest_vmblockenable="YES", EG> vmwareguest_vmhgfsenable="YES", EG> vmwareguest_vmmemctl_enable="YES" и vmware_guestdenable="YES", а EG> вот включать vmwareguest_vmxnetenable я бы не рекомендовал: порт EG> содержит древнючую версию драйвера vmxnet, а в базовой системе уже EG> есть vmxnet3 и гораздо свежее и функциональнее. Спасибо за совет. А то у меня включено всё оптом. EG> Может, и остальные части в базе есть - не разбирался, но точно EG> знаю, что FreeBSD в качестве гостя vmware нормально живёт вообще EG> без open-vm-tools (спроси меня, откуда я это знаю). И откуда ты это знаешь? ) У нас эхотаг тоже хорошо жил без open-vm-tools, но вот выключался плохо. -- Best regards! --- Нotdoged/2.13.5/Android |
#20
|
|||
|
|||
Re: open-vm-tools
Eugene Grosbein написал(а) к Dmitry Kolvakh в Dec 18 08:09:53 по местному времени:
29 дек. 2018, суббота, в 20:07 NOVT, Dmitry Kolvakh написал(а): EG>> И да: open-vm-tools на самом деле не нужен, если только у тебя не EG>> жесточайший highload в виртуалках. DK> Нужен для корректного выключения виртуалки извне Это вообще не должно быть проблемой. Гипервизор разве не умеет посылать через ACPI событие "ACPI power button down"? Оно работает без vm-tools. EG>> Можно, наверное, включить vmwareguest_vmblockenable="YES", EG>> vmwareguest_vmhgfsenable="YES", EG>> vmwareguest_vmmemctl_enable="YES" и vmware_guestdenable="YES", а EG>> вот включать vmwareguest_vmxnetenable я бы не рекомендовал: порт EG>> содержит древнючую версию драйвера vmxnet, а в базовой системе уже EG>> есть vmxnet3 и гораздо свежее и функциональнее. DK> Спасибо за совет. А то у меня включено всё оптом. EG>> Может, и остальные части в базе есть - не разбирался, но точно EG>> знаю, что FreeBSD в качестве гостя vmware нормально живёт вообще EG>> без open-vm-tools (спроси меня, откуда я это знаю). DK> И откуда ты это знаешь? ) У меня есть виртуалки с FreeBSD на разных коммерческих хостингах, включая хостинг с VMWare. Eugene -- Смотри, но не смей трогать --- slrn/1.0.3 (FreeBSD) |