[sisyphus] u: xmms-1.2.8-alt1 to Daedalus

[sisyphus] u: xmms-1.2.8-alt1 to Daedalus

[Michael Shigorin]

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

	Здравствуйте.
В Daedalus incoming ушли пакеты:

libxmms-1.2.8-alt1.i586.rpm
libxmms-devel-1.2.8-alt1.i586.rpm
libxmms-devel-static-1.2.8-alt1.i586.rpm
xmms-1.2.8-alt1.i586.rpm
xmms-1.2.8-alt1.src.rpm
xmms-arts-0.6.0-alt1.i586.rpm
xmms-arts-0.6.0-alt1.src.rpm
xmms-crossfade-0.3.4-alt1.i586.rpm
xmms-crossfade-0.3.4-alt1.src.rpm
xmms-diskwriter-1.2.8-alt1.i586.rpm
xmms-esd-1.2.8-alt1.i586.rpm
xmms-mesa-1.2.8-alt1.i586.rpm
xmms-mikmod-1.2.8-alt1.i586.rpm
xmms-shell-0.99.3-alt1.i586.rpm
xmms-shell-0.99.3-alt1.src.rpm
xmms-vorbis-1.2.8-alt1.i586.rpm

Вкратце:

xmms-1.2.8-alt1: сборка... вспоминая... apache... :)

Основное изменение -- переезд с http://lrn.ru/~rusxmms на
http://rusxmms.sf.net (автор последнего вполне отзывчив, патч
свеж и работоспособен, хотя и подлежит улучшению).

# TODO:
# - review remaining patches; apply/drop/fix
# - update satellite packages (xmms-*)
# - create proper defaults after first run (some wrapper) ?
# - (!) check autodetect of artsd
# - check ru.po's (see 1.2.7 history)
# - uk_UA ackage info
# - spec cleanup

%changelog
* Thu Oct 23 2003 Michael Shigorin <mike@altlinux.ru> 1.2.8-alt1
- 1.2.8
- removed idcin (excluded in upstream)
- changed recode patch to rusxmms.sf.net's version (1.2.8-csa19)
  as it's up to date and active
- removed perversive (gc) build of xmms-shell and sox effects:
  xmms-shell is built separately and sox is outdated (source removed from
  author's site) and widely outperformed by xmms-ladspa)
- fixed patch55 (arts plugin autodetect)
- removed old-forgotten libxmms.so.0 symlink
- spec cleanup

xmms-arts-0.6.0-alt1: обновление; плюс в сам xmms добавлен патч,
который вроде как должен динамически пытаться работать через
xmms-arts/artsd при их доступности, но я его еще не тестировал;
впрочем, вывод через /dev/dsp (напрямую и через xmms-crossfade)
-- OK.

xmms-shell-0.99.3-alt1: вынесен из xmms, потому как такой
извращенной сборки я давно не видел.

xmms-sox при этом просто уронил на пол, поскольку есть
xmms-ladspa.  Желающие sox effects могут сообщить об этом или
опакетить сами, там дел на пять минут.

Вообще есть искушение под шумок принять PLD'шную (или это в
Conectiva?) схему: xmms-$type-$name, где type === { input,
output, effect, vis, other } -- кто что скажет?

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

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

[sisyphus] u: xmms-1.2.8-alt2 to Daedalus; new XMMS policy proposal

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 1922 bytes --]

On Fri, Oct 24, 2003 at 02:37:19PM +0300, Victor Forsyuk wrote:
> > схему: xmms-$type-$name, где type === { input, output,
> > effect, vis, other } -- кто что скажет?
> Двумя руками за.

ACK.

Тогда просьба майнтейнерам других xmms-* пополнить Daedalus
переходом на такой вариант с целью систематизации:

- плагины из Effect/, General/, Input/, Output/, Visualization/
  предлагается содержать в пакетах с именами вида
  xmms-{effect,,in,out,vis}-$name

  Вариант PLD -- {effect,general,input,output,visualisation} --
  проще в плане портирования спеков оттуда, но он недостаточно
  лаконичен (слишком много шума).  Насчет general наличествует
  разнобой, причем мне больше импонируют названия той части
  пакетов, в которой этого префикса нет.

  Посему если более веских аргументов не будет -- оставляю так,
  как нарисовано.

- устойчиво используемые вместе плагины рекомендуется объединять
  виртуальными пакетами; вероятно, будет нечто xmms-full для
  вытягивания всего и вся, прошедшего QA.

- пакеты, содержащие skins, рекомендуется упаковывать как
  xmms-skin-$name (xmms-skins-$name в случае более чем одного
  экземпляра в пакете).
  
- предлагается использовать макросы из /etc/rpm/macros.d/xmms,
  который появится в сборке xmms-1.2.8-alt2 (см. аттач).

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

Мои xmms-*, пересобранные в таком вот аксепте, направляются в
/incoming/Daedalus.

PS: все изменения -- обратно совместимые, поэтому беспокоиться
обновлением пакетов при отсутствии необходимости/времени/желания
_не_ надо.  Например, xmms-shell изменений не потребовал, а
xmms-crystality перепакована вследствие утерянного бинарника.

PPS: для удобства сегодняшние xmms* из PLD spec cvs выложены здесь:
ftp://ftp.altlinux.org/pub/people/mike/misc/xmms-pld-specs.tar.bz2

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

[-- Attachment #1.2: xmms.rpm-macros --]
[-- Type: text/plain, Size: 482 bytes --]

%xmms_version %(rpm -q --queryformat '%{VERSION}' libxmms-devel)
%xmms_release %(rpm -q --queryformat '%{RELEASE}' libxmms-devel)

%xmms_libdir %(xmms-config --plugin-dir)
%xmms_datadir %(xmms-config --data-dir)

%xmms_effectdir %(xmms-config --effect-plugin-dir)
%xmms_generaldir %(xmms-config --general-plugin-dir)
%xmms_inputdir %(xmms-config --input-plugin-dir)
%xmms_outputdir %(xmms-config --output-plugin-dir)
%xmms_visualizationdir %(xmms-config --visualization-plugin-dir)

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

[sisyphus] Re: [devel] new XMMS policy proposal

[Michael Shigorin]

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

On Mon, Oct 27, 2003 at 03:00:51PM +0300, Sergey V Turchin wrote:
> > - устойчиво используемые вместе плагины рекомендуется объединять
> >   виртуальными пакетами; вероятно, будет нечто xmms-full для
> >   вытягивания всего и вся, прошедшего QA.
                  ^^^^^^^^^^^
> Только IMHO использование "full" некорректно, ведь нем не будет
> всего, что есть для xmms.

Ну почему.

> Предлагаю maxi или maximum.

Возможно.  Вообще говоря, не хочется разводить зоопарк, у нас он
и так уже начался и тут -- см. недавнюю дискуссию по поводу
разбиения vegastrike, например.

Есть:

- name{,-common,-subpkg,...}, где
  * name -- виртуальный "полный" пакет;
  * name-commmon -- необходимая общая часть;
  * name-subpkg -- подпакеты.

  +) "поставьте мне kde" => стоит KDE
  -) "ой сколько всего вытягивает это kde!!" => объяснения

- name-{full,minimal,common,subpkg}
  * name-full -- виртуальный "полный" пакет;
  * name-minimal -- виртуальный "минимальный набор";
  * name-commmon, name-subpkg -- см. выше.

  +) появляется "регулятор" вида full/min/joeaverage
  -) может быть не совсем очевидно, как же все-таки поставить
     gnome :)

- name{,-data,-music}
  * name -- необходимая общая часть;
  * name-data -- данные, которые могут (не) изменяться независимо
    по отношению к name;
  * name-music -- данные, которые не являются обязательными.

  +) "более традиционно"
  -) при появлении (например) различных сборок бинарников
     более проблематично сделать вариантность

Мне _в среднем_ более нравится первый вариант, но в таком случае
в головной (и, возможно, подчиненные) вирт. пакеты надо писать
_четкое_ описание того, что они ВИРТУАЛЬНЫЕ и СОБИРАТЕЛЬНЫЕ во
избежание непонимания со стороны пользователей (порой не самых
наивных).

В любом случае могут иметь место и все три варианта -- только в
таком случае желательно как минимум внятно пояснять в _головном_
пакете, что именно _его_ надо устанавливать для получения того-то
и сего-то.  Ну и хорошо бы одной строкой в памятке
пользователя.

Подумал -- task-* здесь не подвязываются, ведь это не runtime, а
install-time task.  Соответственно с реальностью и меню стыковка
разве что случайная.

install-*?  apt-get install install-gnome? :)

В общем, вот этакая затравка для полиси наименования
сложноподчиненных групп пакетов, если есть
комментарии/идеи/оценки -- welcome.

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

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