[devel] Re: ladspa-guitar-*

[Mikhail Yakshin]

Приветствую!

У нас с Юрием Седуновым образовалась вот такая дискуссия, хотелось бы 
послушать ваши мнения на этот счет, поэтому было принято решения вынести 
ее в devel на .

Вот оригинальное предложение Юры ко мне и мой ответ:

============================================================================

> Так уж повелось, что за исключением cmt все LADSPA штепсели в Сизифе для  
> единообразия содержаться в пакетах с названием вида ladspa-*-plugins. Если 
> нет принципиальных возражений, прошу привести названия Ваших пакетов в 
> соответствие с этим простым правилом.

Честно говоря, мне этот *-plugins не очень нравится. Есть следующие
аргументы против такого окончания:

Как правило, если ladspa-* - то сразу видно, что это соответствующий
плагин, потому как иного, насколько я понимаю, быть не может (см. ниже);

ladspa_sdk - пакет довольно странно упакован и, по-моему должен быть
разбит и поименован примерно так:

libladspa - /etc/profile.d
libladspa-devel - *.h, все имеющее отношение к сборке и макросы
libladspa-doc - вся документация, возможно, ее можно включить в -devel
libladspa-utils - утилиты типа listplugins, возможно, их можно включить
в libladspa

Вообще сейчас ситуация с этим пакетом довольно странная. С одной стороны
- по идее рядовому юзеру он должен быть не нужен. С другой стороны -
туда входят такие вроде бы полезные для диагностики (особенно при
использовании чего-нибудь консольного, типа того же ecasound) утилиты
типа listplugins и analyseplugin. С третьей стороны - там переменные дял
профайла. С четвертой стороны - как это ни прискорбно, эти переменные
хотя и должны уважать все LADSPA-enabled программы, но по-нормальному
чтят их похоже только утилиты из этого самого пресловутого SDK, да еще
ecasound, и то не всегда.

Для пакета, видимо, стоит все-таки определить целевую аудиторию и
каким-то образом побить его. Я, конечно, понимаю, что он и так
маленький, но в данном случае речь идет даже не о размере, а о
закладывании базиса для цивилизованной упаковки в пакеты...

Если такой вариант совсем не нравится, то по поводу суффикса хотя бы
стоит подумать о следующих предложениях. Суффикс -plugins - это
идеологически имхо очень неверно, суффиксами у нас обозначаются некие
части пакетов или их разновидности (-devel, -headers, -docs, -utils),
разные бинарные сборки (xemacs-mule, xemacs-nomule) и т.п., а типы
пакетов как раз обозначаются в префиксе, если таковой есть. То есть
наличие суффикса -plugins подразумевает, что, наверное, есть такой же
пакет, только без -plugins? Его, разумеется, нет.

Дальше, сам суффиксы -plugins мне категорически не нравится из-за
множественного числа. Это сейчас уже неправда, не считая моих 3
плагинов, есть по-моему еще 2, где плагины упакованы по одиночке, да и в
целом это более стандартная, по-моему тенденция. Вообще это по-моему
более unix way (не люблю очень такую формулировку, очень флеймоопасная,
но, надеюсь, Вы меня правильно поймете) тенденция называть вещи в
единственном числе.

В сизифе ситуация обстоит примерно так:

$ apt-cache search plugin\\b |wc -l
     179
$ apt-cache search plugins |wc -l
      99

Первое ищет написание plugin одним словом без окончания "s", второе -
plugins в множественном числе. Вообще, может быть тут стоит провести
некую локальную революцию в Сизифе на эту тему и описать такое каким-то
образом в полиси?..

xmms вот сейчас переходит на префиксную схему, но там, см. выше, есть
из-за чего - там схема "xmms-название", разумеется, не годится, из-за
того, что плагины бывают разные, а еще из-за того, что есть пакет xmms с
его частями -devel и т.п. Нам же по-моему тут вполне можно обойтись
"ladspa-название".

Было бы здорово, пока плагинов относительно немного, перейти на более
четкую идеологически схему, чем "так повелось".

============================================================================

Еще одно добавление: у меня есть такой пакет, как ladpsa-guitar-doc - 
там документация (так как к каждому плагину ее отдельно нет, это просто 
снапшот сайта автора, сильно проясняющий ситуацию плюс там же запакованы 
мои пресеты для ecasound realtime processing, которые используют все 
плагины семейства - к какому-то одному их тоже бонусом не запакуешь). 
Вот такие вот соображения.

WBR, Mikhail Yakshin