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