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

[Michael Shigorin <mike@osdn.org.ua>]

[-- 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 --]