[devel] Re: ladspa-guitar-*

[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

[devel] [POLICY] A-[plugin]->B (was: ladspa-guitar-*)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 3764 bytes --]

On Fri, Jan 02, 2004 at 08:24:51PM +0300, Mikhail Yakshin wrote:
> ladspa_sdk - пакет довольно странно упакован и, по-моему должен быть
> разбит и поименован примерно так:
> libladspa - /etc/profile.d
> libladspa-devel - *.h, все имеющее отношение к сборке и макросы
> libladspa-doc - вся документация, возможно, ее можно включить в -devel
> libladspa-utils - утилиты типа listplugins, возможно, их можно включить
> в libladspa

Я бы (с низким приоритетом) высказался за ladspa-common или даже
просто ladspa; вынос "всего имеющего отношения к сборке" в какой
(lib)?ladspa-devel еще может быть осмыслен -- но вот разносить
копеечные утилиты и документацию по отдельным пакетам -- IMCO
бессмысленно.

В общем, спорим, не подеретесь. :)

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

А цивилизованная упаковка для пакетов по два кило без кошмарных
зависимостей бессмысленна.  Грузите апельсины бочками, и все тут.

> Дальше, сам суффиксы -plugins мне категорически не нравится

Даже без множественного числа навешивание *и* префикса, *и*
суффикса выглядит действительно чуточку ой.  Это да.

> Вообще, может быть тут стоит провести некую локальную революцию

Это называется cleanup.  (в сторону: ну там .la cleanup... ;)

> в Сизифе на эту тему и описать такое каким-то образом в
> полиси?..

Бесспорно.  Не хотите пройтись по e.g. Debian policy [1],
существующему ALT Packaging HOWTO [2] и недостающее во втором
написать и прислать в docs@ ?

Как вариант -- можете подключиться к созданию [3], но это по
большей части моя отсебятина.

> xmms вот сейчас переходит на префиксную схему, но там, см.
> выше, есть из-за чего - там схема "xmms-название", разумеется,
> не годится

Разумеется, годится.  Просто без разделения плагинов по "кучкам" 
общая куча нарастала как-то совсем неправильно, и это при том,
что неопакеченных (и стоящих того) еще есть.

При этом для general plugins в результате размышлений и вопросов
было оставлено простое наименование "xmms-$plugin": они слишком
разношерстные, а субпрефикс "gen-" тут информативности не
добавлял.

> из-за того, что плагины бывают разные, а еще из-за того, что
> есть пакет xmms с его частями -devel и т.п.

Строго говоря, libxmms-devel. :)

> Нам же по-моему тут вполне можно обойтись "ladspa-название".

Если 

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

Кстати, пока у темы: есть предложение зафиксировать рекомендацию:

	При ситуации "исходный пакет A дает подключаемый модуль
	(плагин) для использования с пакетом B" (модули к xmms,
	multisync, ...) следует использовать название пакета с
	таким модулем в виде B-A, т.е. отталкиваясь от "пункта
	назначения", с целью группирования пакетов по названию
	около: 1) необходимого; 2) базового; 3) того, "для"
	которого будет востребована добавляемая функциональность.

	Если пакет с оригинальным названием существовал
	(существует) в Sisyphus или широко распространен в виде
	сторонних сборок, следует добавить в spec-файл тег
	"Obsoletes: старое_название".

	При этом несоответствие названия в upstream не должно
	быть препятствием; например, возможно переименовать imms
	в xmms-imms или synce-multisync_plugin в multisync-synce.

В данном случае это применимо к gstreamer-ladspa / xmms-ladspa.
Ура, я не один в этих соображениях :)

[1] http://www.debian.org/doc/debian-policy/
[2] http://docs.altlinux.ru/alt/devel/ch01.html
[3] http://wiki.atmsk.ru/index.html/AltPolicy

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [POLICY] A-[plugin]->B

[Mikhail Yakshin]

Michael Shigorin пишет:

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

> Я бы (с низким приоритетом) высказался за ladspa-common или даже
> просто ladspa; вынос "всего имеющего отношения к сборке" в какой
> (lib)?ladspa-devel еще может быть осмыслен -- но вот разносить
> копеечные утилиты и документацию по отдельным пакетам -- IMCO
> бессмысленно.

> В общем, спорим, не подеретесь. :)

Я могу еще раз объяснить вышеприведенные пожелания с точки зрения 
различных сценариев использования пакета.

1. Конечный пользователь. Ставит себе libladspa на несколько килобайт и 
успокаивается.

2. Пытливый конечный пользователь. Ставит себе в придачу к 1 еще 
libladspa-utils.

3. Сборщик софта, требующего LADSPA. Ставит себе libladspa + 
libladspa-devel и больше ему ничего не нужно.

4. Разработчик самих плагинов - ставит себе полный набор - вместе с 
документацией, вместе с libladspa-devel и утилитами.

Какие из этих классов можно приравнять друг к другу - большой вопрос. В 
моем представлении, можно объединить 1 и 2, сильно спорно - 3 и 4.

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

> А цивилизованная упаковка для пакетов по два кило без кошмарных
> зависимостей бессмысленна.  Грузите апельсины бочками, и все тут.

Я более-менее выше объяснил, какие могут быть классы пользователей и что 
им ставить. Зависимости по-моему тривиально ясны:

libladspa-utils requires libladspa
libladspa-devel requires libladspa
libladspa-doc require libladspa, может быть еще libladspa-devel
Любой конечный плагин requires libladspa

>>Дальше, сам суффиксы -plugins мне категорически не нравится
> 
> Даже без множественного числа навешивание *и* префикса, *и*
> суффикса выглядит действительно чуточку ой.  Это да.

На самом деле на эту тему в сизифе творится вообще полный бардак IMHO. 
Достаточно сделать apt-cache search plugin и посмотреть :(

>>Вообще, может быть тут стоит провести некую локальную революцию
> 
> Это называется cleanup.  (в сторону: ну там .la cleanup... ;)

Ну да, ну да ;)

>>в Сизифе на эту тему и описать такое каким-то образом в
>>полиси?..
> 
> Бесспорно.  Не хотите пройтись по e.g. Debian policy [1],
> существующему ALT Packaging HOWTO [2] и недостающее во втором
> написать и прислать в docs@ ?

В ALT Packaging HOWTO ничего про плагинные сборки вообще я ничего не 
нахожу, в Debian policy - хорошо, спасибо за ссылку, посмотрю.

> Как вариант -- можете подключиться к созданию [3], но это по
> большей части моя отсебятина.

Оно же вроде бы умерло? www.linux-os.ru сейчас или что там у нас?..

>>xmms вот сейчас переходит на префиксную схему, но там, см.
>>выше, есть из-за чего - там схема "xmms-название", разумеется,
>>не годится
> 
> Разумеется, годится.  Просто без разделения плагинов по "кучкам" 
> общая куча нарастала как-то совсем неправильно, и это при том,
> что неопакеченных (и стоящих того) еще есть.

Ну, а еще пакеты можно просто понумеровать. И быстрее будет работать, и 
вообще более тру. Фразы в стиле 12892 пакет requires 9273 %) Или там MD5 
от названия чего-нибудь взять и в качестве имени пакета... %)

Мы говорим сейчас не о том, что "годится" в смысле минимальных 
требований для выживания, а о хорошей базе на будущее...

> Кстати, пока у темы: есть предложение зафиксировать рекомендацию:
> 
> 	При ситуации "исходный пакет A дает подключаемый модуль
> 	(плагин) для использования с пакетом B" (модули к xmms,
> 	multisync, ...) следует использовать название пакета с
> 	таким модулем в виде B-A, т.е. отталкиваясь от "пункта
> 	назначения", с целью группирования пакетов по названию
> 	около: 1) необходимого; 2) базового; 3) того, "для"
> 	которого будет востребована добавляемая функциональность.
> 
> 	Если пакет с оригинальным названием существовал
> 	(существует) в Sisyphus или широко распространен в виде
> 	сторонних сборок, следует добавить в spec-файл тег
> 	"Obsoletes: старое_название".
> 
> 	При этом несоответствие названия в upstream не должно
> 	быть препятствием; например, возможно переименовать imms
> 	в xmms-imms или synce-multisync_plugin в multisync-synce.

Я - за.

WBR, GreyCat.

[devel] Re: [POLICY] A-[plugin]->B

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

On Sat, Jan 03, 2004 at 01:07:13AM +0300, Mikhail Yakshin wrote:
> Я могу еще раз объяснить вышеприведенные пожелания с точки
> зрения различных сценариев использования пакета.

Да я их прекрасно понимаю.  Но, видите ли, реальность
заключается не только в различиях, но и в сходствах.  И если
разбиение пакетов помогает не только "навести на резкость", но и
сэкономить те же ресурсы (или уменьшить энтропию системы) -- то
злоупотребление таковым _увеличивает_ фактическое потребление
ресурсов и энтропию как системы, так и репозитория.

> 1. Конечный пользователь. Ставит себе libladspa на несколько
> килобайт и успокаивается.
> 2. Пытливый конечный пользователь. Ставит себе в придачу к 1
> еще libladspa-utils.

...на еще несколько килобайт.

> 3. Сборщик софта, требующего LADSPA. Ставит себе libladspa +
> libladspa-devel и больше ему ничего не нужно.
> 4. Разработчик самих плагинов - ставит себе полный набор -
> вместе с документацией, вместе с libladspa-devel и утилитами.

...на еще несколько килобайт.

> Какие из этих классов можно приравнять друг к другу - большой
> вопрос. В моем представлении, можно объединить 1 и 2, сильно
> спорно - 3 и 4.

Смотрю я на этот пакет и думаю (повторно).  И опять не понимаю --
зачем этот атом резать на нуклоны?  Фундаментально оно, конечно,
интересно и концептуально целостно -- но смысла-то -- не видно.

Будь там по полмегабайта на подпакет или по шапке зависимостей --
понятно.  А так -- трафик по теме уже превысил цену вопроса.

> >А цивилизованная упаковка для пакетов по два кило без кошмарных
> >зависимостей бессмысленна.  Грузите апельсины бочками, и все тут.
> Я более-менее выше объяснил, какие могут быть классы
> пользователей и что им ставить.

Знаете, я достаточно уже тут (и не только) всем уши прожужжал и
про классы пользователей, и про кластеры пакетов вокруг задач.

Повторюсь -- в данном конкретном случае смысла не вижу никакого.

> Зависимости по-моему тривиально ясны:
> libladspa-utils requires libladspa
> libladspa-devel requires libladspa

Ну.

> libladspa-doc require libladspa, может быть еще libladspa-devel

Есть желание сэкономить на utils и devel?  26k бинарников и 27 --
хедера?  du -sh /var/lib/rpm давно не видели?

Шара -- она, как ни крути, боком вылазит.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: [POLICY] A-[plugin]->B

[Mikhail Yakshin]

Michael Shigorin пишет:
> On Sat, Jan 03, 2004 at 01:07:13AM +0300, Mikhail Yakshin wrote:
> 
>>Я могу еще раз объяснить вышеприведенные пожелания с точки
>>зрения различных сценариев использования пакета.
> 
> 
> Да я их прекрасно понимаю.  Но, видите ли, реальность
> заключается не только в различиях, но и в сходствах.  И если
> разбиение пакетов помогает не только "навести на резкость", но и
> сэкономить те же ресурсы (или уменьшить энтропию системы) -- то
> злоупотребление таковым _увеличивает_ фактическое потребление
> ресурсов и энтропию как системы, так и репозитория.

<skip/>

> Есть желание сэкономить на utils и devel?  26k бинарников и 27 --
> хедера?  du -sh /var/lib/rpm давно не видели?
> 
> Шара -- она, как ни крути, боком вылазит.

Вообще мне более или менее все равно - как паковать этот пакет и на 
сколько частей его разбивать - решать мейнтейнеру. Я бы на его месте 
остановился на решении минимального пакета ladspa для юзера и 
ladspa-devel со всем остальным (с документацией, утилитками и хедером). 
Хотите сделать ladspa-common или просто ladspa - ok. А вот текущее имя 
ladspa_sdk меня не сильно устраивает, так как во-первых, выглядит дико 
нестандартно, во-вторых, не отражает сути содержимого.

Разговор, насколько я помню, шел о том, как именовать сами пакеты с 
плагинами, вместо развесистой схемы ladspa-.*-plugin[s]?

Есть какие-то предложения по теме, кроме моих?

Средний по быстроте взгляд на дебиановские полиси ничего на тему 
плагинов вообще и LADSPA в частности не дал. Ни в 11 разделе (customized 
software), ни в первоочередных полисях на тему названий и т.п. Поиск по 
их спискам рассылки дал только одно дельное предложение: организовать 
виртуальные пакеты ladspa-host и ladspa-plugin, при этом, соответственно 
каждый хост провайдит ladspa-host, а каждый плагин является 
ladspa-plugin. Зачем это надо - ставить какой-то дефолтовый хост при 
установке первого плагина в систему?.. - я не понимаю...

С наименованиями самих пакетов у них по-моему тоже полный бардак. Даже 
хуже, чем у нас - вроде бы заявляются пакеты с именами "cmt" и "swh".

Чего будем делать?

// Почти оффтопик: вот какая у меня мысль нехорошая появилась. Есть у 
нас вот такие вот пакеты - очень мелкие, которые бить идеологически 
*надо*, а вот с практической точки зрения - не стоит. Но всегда 
существует вероятность того, что в будущем релизе пакет вырастет 
настолько, что разбить его будет уже целесообразно и практично. Причем 
определить эту границу, когда это стоит делать мы ведь можем - это очень 
просто - надо сравнить:

[размер цельного пакета + 1 записи в rpm db]
  vs
[размер основного кусочка + n записей в rpm db]

Вопрос к знатокам техпроцесса Сизифа - можно ли это автоматизировать? 
Скажем, чтобы в хэшере при пересборке пакет мог самооцениваться и 
собираться автоматически в зависимости от приведенного выше соотношения 
либо в цельный пакет, либо в несколько "кусочных". При такой постановке 
вопроса человеческий аспект решения проблемы - что нам лучше - целиком 
или кусками - пропадает навсегда - ответ все автоматический - чем мельче 
- тем лучше. Оно потом все равно само что нужно сольет...

Если это возможно - я в силу своих возможностей могу помочь в 
реализации, особенно в алгоритмике такой задачки - благо некий опыт есть 
%) Было бы интересно...

WBR, GreyCat

Re: [devel] [POLICY] A-[plugin]->B

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On Fri, Jan 02, 2004 at 08:39:31PM +0200, Michael Shigorin wrote:
> On Fri, Jan 02, 2004 at 08:24:51PM +0300, Mikhail Yakshin wrote:
> 	Если пакет с оригинальным названием существовал
> 	(существует) в Sisyphus или широко распространен в виде
> 	сторонних сборок, следует добавить в spec-файл тег
> 	"Obsoletes: старое_название".

А также (безотносительно к обсуждаемой теме)
Provides: старое_название = %version-%release


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: [POLICY] A-[plugin]->B

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Sat, Jan 03, 2004 at 02:01:45AM +0300, Dmitry V. Levin wrote:
> > 	Если пакет с оригинальным названием существовал
> > 	(существует) в Sisyphus или широко распространен в виде
> > 	сторонних сборок, следует добавить в spec-файл тег
> > 	"Obsoletes: старое_название".
> А также (безотносительно к обсуждаемой теме)
> Provides: старое_название = %version-%release

Да, конечно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]