Вопрос скорее к _авторам_ sshfs-fuse, encfs, SieFS (кстати, на два последних я
подобных записей в bugzilla не нашёл) и остальных проектов, перечисленных на
странице http://fuse.sourceforge.net/filesystems.html

Лично мне не нравится называть пакет fuse-sshfs по двум причинам:

1) частная причина - исходный тарбол всё же называется sshfs-fuse;

2) общая причина - по-моему, в рассылках уже обсуждался вопрос о
целесообразности переименований такого рода; надо решить, к чему ближе
sshfs-fuse, к а) разумному переименованию pygtk -> python-module-pygtk, или б)
совсем ненужному переименованию ups-monitor -> pygtk-ups-monitor

На мой взгляд, идеология fuse немного отличается от lufs. В lufs новые ФС
реализуются как плагины, в виде /usr/lib/liblufs-*.so*. В fuse ситуация другая,
sshfs - это самостоятельный исполняемый ELF-файл, слинкованный с libfuse.so.*.
Именно поэтому переименование sshfs-fuse -> fuse-sshfs для меня похоже на
переименование ups-monitor -> pygtk-ups-monitor.

Другой вопрос - как рассматривать отношения sshfs с fusermount. Тут
действительно, отсутствие зависимости на пакет fuse, - мой промах. Без
fusermount не отмонтируешь смонтированную sshfs ( #6599 ). Большего, по-моему,
не нужно. Зависимости и так расскажут интересующимся, что к чему.

Либо назовите 'fuse-sshfs', либо 'sshfs'. 'sshfs-fuse' это некосистентно.

Если "материнский" пакет упоминается, он должен упоминаться в начале названия,
либо не упоминаться вообще.

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

И, если у вас нет возражений, разрешить мне (с уведомлением incoming@) обновлять
пакет, ибо при обновлениях fuse иногда приходится обновлять _все_ зависящие от
него пакеты.

(In reply to comment #2)
> Либо назовите 'fuse-sshfs', либо 'sshfs'. 'sshfs-fuse' это некосистентно.
> 
> Если "материнский" пакет упоминается, он должен упоминаться в начале названия,
> либо не упоминаться вообще.

Ну я же написал с самого начала, что это пожелания автору sshfs-fuse, Miklos
Szeredi. "I worship his shadow" (c) LEXX :-)

Переименовать мне нетрудно, право слово, но, по-моему, это бессмысленное
действие. В природе есть проект sshfs-fuse. Имена sshfs и fuse-sshfs, строго
говоря, не имеют отношения к этому конкретно взятому проекту. Пока _автор_ не
решит иначе.

> 
> Кроме того, все зависящие от fuse проекты очень сильно зависят от версии fuse.
> Посему настоятельно прошу переименовать в fuse-sshfs.

Хорошо, переименую. "Дурное дело - не хитрое" :-)

> 
> И, если у вас нет возражений, разрешить мне (с уведомлением incoming@) обновлять
> пакет, ибо при обновлениях fuse иногда приходится обновлять _все_ зависящие от
> него пакеты.
 
Интуитивно я догадываюсь, но всё же не побоюсь уточнить - как выражается сильная
зависимость от версии fuse? Перефразирую, что может быть сильнее зависимости от
libfuse.so.2(FUSE_2.2)? Честно говоря, я удивился увидеть в libfuse "Symbol
Versions". Обычно такой подход применяется в glibc для того, чтобы тащить в
одной библиотеке сразу несколько ABI для совместимости с несвободными
программами, собранными под LSB.

Обычно с пересборками, которые нужны по причине изменений ABI, справляется робот.

Отчего в спеке encfs такая негибкая зависимость Requires: fuse = %{get_SVR
fuse}? Не берусь судить окончательно, но на первый взгляд похоже на решение
нетехнических проблем техническими средствами. Больше удивляет отсутствие
зависимости двоичного пакета fuse от libfuse = %{get_SVR fuse}. fusermount
действительно работает с любой версией и сборкой libfuse? По зависимостям
выглядит именно так. Существующее положение выглядит как попытка форсировать
обновление пакета fuse при обновлении пакетов, _зависящих_ от libfuse, т.к.
обновление только пакета libfuse оставляет старый пакет fuse.

Мне кажется, что здесь именно libfuse играет "первую скрипку"... Хотелось бы
знать причину наличия в спеке encfs зависимости от fuse = %{get_SVR fuse},
потому что, по-идее, то же самое должно быть и в fuse-sshfs.

Я помню что-то подобное в районе python-module-PyQt и зависимости от конкретной
сборки Qt. Так, судя по changelog, там уже давно "вкалывают роботы, а не
человек", см.
http://www.linux.kiev.ua/devel/RPM/SPECS/classic/python-module-PyQt.spec

Итак, если возражений не будет, следующая версия пойдёт под именем sshfs.

Так будет консистентно с encfs и alterator-admfs, а также совпадать с именем
команды sshfs.

Что с зависимостью от fuse = %{get_SVR fuse}? Ставить в следующую сборку sshfs
эту зависимость, или всё-таки сначала пакет fuse начнёт зависеть от пакета
libfuse и этим всё ограничится?

encfs будет переименован. Как мантейнер говорю.

fuse, как ни странно, не требует libfuse само по себе (посмотрите на ldd fuse).

libfuse, в свою очередь, _должна_ требовать fuse конкретной версии. То, что это
не так -- бага. Спасибо, сегодня будет сборка без этой баги.

Столь жёсткая зависимость сделана потому, что у меня был по крайней мере два
случая, когда пакет не работал после обновления fuse. Один яркий пример -- SieFS
до сих пор лежит в сизифе. Неработоспособный, потому как собран с одной версией
fuse, а не с более новой.

(In reply to comment #5)
> encfs будет переименован. Как мантейнер говорю.

Хорошо, как только я увижу образец (насколько я понял, encfs -> fuse-encfs,
верно?) - синхронизирую.

> 
> fuse, как ни странно, не требует libfuse само по себе (посмотрите на ldd fuse).
> 

Я видел :-)

> libfuse, в свою очередь, _должна_ требовать fuse конкретной версии. То, что это
> не так -- бага. Спасибо, сегодня будет сборка без этой баги.

Не до конца понимаю, зачем libfuse должна зависеть от fuse, а не наоборот.
Попытаюсь объяснить. Есть fuse-sshfs, линкуемый в данный момент с libfuse.so.2.
Т.о. установка пакета fuse-sshfs автоматически установит libfuse. Далее -
команда sshfs отлично работает как в присутствии пакета fuse, так и в его
отсутствие. Есть только одно неудобство - без fuse нельзя отмонтировать sshfs.
Поэтому я повесил на sshfs #6599. Пока всё хорошо, установка sshfs будет
требовать установить fuse. Осталась одна тонкость - при наличии пакета fuse в
системе к моменту установки fuse-sshfs этот имеющийся fuse не будет обновлён до
версии, соответствующей текущей версии пакета libfuse. *Зависимость fuse от
конкретной версии libfuse* решает и эту проблему. В системе не сможет жить
старый fuse, отстающий по версиям от libfuse.

А вот *зависимость libfuse от fuse*... Для меня она противоестественна хотя бы в
силу того, что в hasher при сборке пакетов, зависящих от libfuse, будет
ставиться совершенно ненужный пакет fuse. Я занимаюсь сборкой, при чём здесь
fusermount?

> 
> Столь жёсткая зависимость сделана потому, что у меня был по крайней мере два
> случая, когда пакет не работал после обновления fuse. Один яркий пример -- SieFS
> до сих пор лежит в сизифе. Неработоспособный, потому как собран с одной версией
> fuse, а не с более новой.

А можно узнать о втором случае? Потому что SieFS уж очень странный какой-то:

1) $ apt-cache showpkg SieFS

Package: SieFS
Versions: 
0.2-alt4(/var/lib/apt/lists/ftp.altlinux.com_pub_distributions_ALTLinux_Sisyphus_i586_base_pkglist.classic)

Reverse Depends: 
Dependencies: 
0.2-alt4 - mount (2 2.11) FUSE (0 (null)) /bin/sh (0 (null)) /bin/sh (0 (null))
libc.so.6 (0 (null)) libc.so.6(GLIBC_2.0) (0 (null)) libc.so.6(GLIBC_2.1) (0
(null)) libc.so.6(GLIBC_2.1.3) (0 (null)) libpthread.so.0 (0 (null))
libpthread.so.0(GLIBC_2.0) (0 (null)) libpthread.so.0(GLIBC_2.1) (0 (null)) 
Provides: 
0.2-alt4 - 
Reverse Provides: 

2) $ apt-cache showpkg libfuse.so.2
Package: libfuse.so.2
Versions: 

Reverse Depends: 
  sshfs-fuse,libfuse.so.2
  encfs,libfuse.so.2
  alterator-admfs,libfuse.so.2
Dependencies: 
Provides: 
Reverse Provides: 
libfuse 2.2-alt5

Т.е., если у libfuse сменится soname - sshfs-fuse, encfs, alterator-admfs сразу
же перестанут жить, т.к. будут вынесены при обновлении libfuse. Зависимость от
libfuse.so.2 выставляется автоматически при сборке двоичного пакета. SieFS стоит
особняком - почему? Статическая линковка? (признаю, лень посмотреть исходники :-) )

1. Если пакет требует libfuse, значит ему нужен fusermount. Поэтому libfuse
должен тянуть за собой fuse. Сам по себе пакет fuse никому не нужен, это
обёртка. Поэтому и зависеть должен libfuse от fuse, а не наоборот. Поэтому я
добавил в libfuse зависимость на fuse = %version-%release. Единственный
действительно серьёзный аргумент против -- сборка в hasher'е. Однако думаю что
установка такого маленького пакета никому не повредит.

2. fuse-encfs и fuse-siefs лежат в incoming/

3. Хрен его знает, почему SieFS такой странный. Я уже попросил вынести его из
репозитория (его мантейнер уже давно недоступен).

(In reply to comment #7)
> 1. Если пакет требует libfuse, значит ему нужен fusermount. Поэтому libfuse
> должен тянуть за собой fuse. Сам по себе пакет fuse никому не нужен, это
> обёртка. Поэтому и зависеть должен libfuse от fuse, а не наоборот. Поэтому я
> добавил в libfuse зависимость на fuse = %version-%release. Единственный
> действительно серьёзный аргумент против -- сборка в hasher'е. Однако думаю что
> установка такого маленького пакета никому не повредит.

Пусть будет так.

> 
> 2. fuse-encfs и fuse-siefs лежат в incoming/

Получил при dist-upgrade fuse-2.2-alt6. Работоспособность sshfs-fuse-1.1-alt1,
собранного с fuse-2.2-alt5, не нарушилась. Поэтому я пока не вижу смысла ставить
в спеке fuse-sshfs зависимость от fuse = %{get_SVR fuse} и делать пересборки на
каждую пересборку fuse.

Если что-то сломается, будем разбираться сообща. Я против "пересборки не глядя"
как серебряной пули.

<skip/>

Если вы знаете замену get_SVR, не привязывающуюся к release, можно её использовать.

От release ничего не зависит.

А при смене версии бинарную совместимость они уже ломали.

(In reply to comment #9)
> Если вы знаете замену get_SVR, не привязывающуюся к release, можно её
использовать.

%(echo Requires: `rpmquery --queryformat "%{NAME} = %{VERSION}" fuse`)

> 
> От release ничего не зависит.
> 
> А при смене версии бинарную совместимость они уже ломали.

Т.е. сменили ABI без изменения soname? Плохо. У вас есть силы и время
воздействовать на upstream fuse, чтоб исправлять эту досадную оплошность, что
называется, "в консерватории"? Вышеприведённый Requires - всё же костыль.

1. Я не настолько хорошо знаю RPM. Если этот хак работает -- это отличное решение.

2. Лень. И не вижу смысла. Так как поддержка fuse скоро будет в vanilla kernel,
скоро им и без меня за любые глубости устроят курс обучения программированию.

(In reply to comment #11)
> 1. Я не настолько хорошо знаю RPM. Если этот хак работает -- это отличное решение.

Работает. Главное условие работы - наличие установленного fuse в сборочной
среде. То, что libfuse зависит от fuse, - обеспечивает выполнение этого условия.
Иначе пришлось бы вписывать "BuildRequires: fuse".

fuse-sshfs-1.1-alt2 с этим хаком уже отправлен в i/S.

/me счастлив