Предлагается рассмотреть вопрос о назывании пакетов, использующих fuse, как fuse-sshfs.
Вопрос скорее к _авторам_ 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 счастлив
