Re: [devel] Принцип опакечивания sim (was: Хочу новый sim в Сизиф!)

[Andrey Rahmatullin <wrar@yandex.ru>]

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

On Mon, Feb 16, 2004 at 05:26:22PM +0300, Vitaly Lipatov wrote:
> > Я разбирался в Альбертовской системе сборки, понял, что из
> > sim-source.src.rpm собирается sim-source.noarch и
> > sim-common.noarch с звуками, картинками и локалями. С
> > использованием sim-source.noarch из 2 спеков собираются sim
> > (КДЕшный) и sim-qt (без КДЕ). Они оба используют
> > sim-common.noarch. По-моему, по-другому нельзя.
> А почему нельзя в одном спеке это сделать?

Ситуация такая. В Мастере sim-0.8.1 состоит из sim, sim-qt и sim-data,
собиравшихся из одного спека. В 0.9.0-alt0.1 (скорее всего) появился
sim-source, а из 2 спеков стали собираться sim+libsim+sim-data и
аналогично для -qt (причин для выделения libsim не вижу). В 0.9.0-alt0.9 и
выше sim-common собирается из sim-source.src.rpm, при том весьма странно
(там отдельный тарболл с sim-common, выковырянный из рез-тов make install,
т.к. *.ро, в частности, из сырцов просто так не получишь), а в отдельные
пакеты вынесены еще и sim-plugins. Опять-таки, не пойму, зачем. Судя по
Conflicts, допустимо иметь плагины от кдешной сборки, а либу от обычной
etc. Но тем не менее...

Итак, предлагается из 1 спека и тарболла собирать
sim
sim-qt
sim-common

и всё.

Или кто-то объяснит глубинный смысл развода по пакетам проги, либы и
плагинов, если они друг друга требуют с точностью до релиза?

Кстати, zerg, судя по чейнджлогу, помогал разводу в части проставления
конфликтов, может, он чего объяснит?


И еще. нужна ли нам локализация на 19 языков? Без нее пакет будет хоть
немного полегче:
bg
ca
cs
de
el
es
fr
he
hu
it
nl
pl
pt_BR
ru
sk
sw
tr
uk
zh_TW



-- 
WBR, wRAR (ALT Linux Team)

> [...] И сразу вопрос: Что такое "AVL tree" и как его перевести,
> чтобы программисты тоже поняли ;) ?
 Нельзя перевести. "Деревья Адельсона-Вельски да Ландиса" не канает. ;)
Правда, можно "H-балансированные бинарные деревья" написать...
		-- vsl in devel@

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