[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