On Wed, Jan 23, 2008 at 11:06:57PM +0300, Dmitry V. Levin wrote:
> > Кроме "прежде всего" выяснения, есть ли вообще такое дело,
> > нам нужно также соблюдать баланс между 1) возможностью перемещения
> > команды между каталогами PATH, из-за чего нежелательно ставить
> > файловую зависимость; 2) сохранить зависимость достаточно виртуальной,
> > чтобы облегчить переименование пакетов, из-за чего нежелательно ставить
> > зависимость на имя пакета.  Понятно, что эти пункты противоречат друг
> > другу.  Если бы можно было "отсрочить" сразу два этих пункта, тогда бы
> > мы могли получить бОльшую независимость от contents_index_*.
> > 
> > Можно было бы отсрочить это введением дополнительного неймспеса
> > зависимостей executable(...) -- возможно, с поддержкой со стороны
> > rpm и apt.
> 
> Вопрос в том, настолько ли часто executables перемещаются по $PATH или
> по пакетам, чтобы затеять менену contents_index на executable(...)?

Проблема, конечно, не очень острая.

Всё-таки вот конкретный пример/вопрос: в скрипте есть команда mksock.
Есть файл /usr/bin/mksock и пакет coreutils.  Какую зависимость
предпочитительнее поставить: /usr/bin/mksock или coreutils?

Пока для поиска команд мне видится вот что:
1) Если есть всего один путь (при любом числе пакетов), будет путь;
в противном случае
2) если есть всего один пакет (при любом числе путей), будет пакет;
в противном случае
3) примерно как сейчас: приоритет путей, fallback to host environmet,
последний fallback опять на приоритет путей.

Что это даёт?  Мы избавляемся от названий пакетов, в ущерб возможности
перемещения путей по PATH; если же PATH уже обильно населён (типа gawk:
/bin/awk, /usr/bin/awk; ещё хуже -- ruby: /bin/ruby, /usr/bin/ruby),
значит пакет "держит" свою команду крепко, а выбрать путь сложно.

Правда, если это наивано реализовать, то как из рога изобилия посыпутся
зависимости /bin/cat, /bin/rm, /bin/mv и т.п.  В принципе самые
неотъемлемые команды из coreutils можно как-нибудь оптимизировать.