Bug 16273

собственно, что в обсуждаемом пакете этому препятствует ?
дефолтный конфиг нужный модуль грузит.
осталось всего ничего -- пересобрать esound, выделив в отдельный подпакет
libesd.s0.*.

я готовлю к выпуску pulseaudio 0.9.11
было бы хорошо оперативно определиться с пожеланиями
к пакету и судьбой esound.

Мне идея нравится. Юрий, есть какие-то сложности?

libesd у нас теперь есть, -- можно попробовать собрать пакет pulseaudio-esd, который должен также провайдить esound.

вопросы:
а) зачем выделять подпакет pulseaudio-esd ?
бэ) а сам esound сохраняется ? если да, это нехорошо,
виртуальный esound и реальный esound -- это путь к проблемам,
мне кажется. было бы удачнее сделать подпакет esound-daemon, который
предоставляет, как и pulseaudio-daemon, две сущноcти:
esound и /usr/bin/esd, сам же пакет esound упразднить.

(In reply to comment #5)
> вопросы:
> а) зачем выделять подпакет pulseaudio-esd ?
> бэ) а сам esound сохраняется ? если да, это нехорошо,
> виртуальный esound и реальный esound -- это путь к проблемам,
> мне кажется. было бы удачнее сделать подпакет esound-daemon, который
> предоставляет, как и pulseaudio-daemon, две сущноcти:
> esound и /usr/bin/esd, сам же пакет esound упразднить.
> 

Мне кажется, что совсем убить настоящий esound всегда успеем, -- сперва хочется убедиться, что pulseaudio  в виде esdcompat работает не хуже.

ок, моя часть работы в любом разе одна и та же.

а, стоп. не одна и та же. Шизофрения получится:
Provides: esound и
Conflicts: esound (из-за /usr/bin/esd)
Так что нужно делать esound-daemon.
Я ничего не путаю ?

(In reply to comment #8)
> а, стоп. не одна и та же. Шизофрения получится:
> Provides: esound и
> Conflicts: esound (из-за /usr/bin/esd)
> Так что нужно делать esound-daemon.
> Я ничего не путаю ?
> 

Если я ничего не путаю, то достаточно Provides: esound.

Лучше всё-таки сделать esound-daemon, или esound-legacy, скажем. Помимо шизофрении (если сделать только Provides: esound, то можно будет установить оба пакета сразу), apt не слишком адекватен, когда дело касается выбора между пакетом <имя-реального-пакета> и пакетом, провайдящим <имя-реального-пакета>.

> если сделать только Provides: esound, то можно будет установить оба пакета
> сразу
можно будет _попытаться_ установить оба пакета сразу и
тут же обломаться из-за /usr/bin/esd, наличествующего и там,
и там. Так что Conflicts: нужен, осталось выяснить,
как будет называться пакет, содержащий esound'овский
/usr/bin/esd (не esound -- мы уже договорились, как я понимаю).
Ожидаю также увидеть в таком пакете Conflicts: pulseaudio-daemon
Принято ?

(In reply to comment #11)
> > если сделать только Provides: esound, то можно будет установить оба пакета
> > сразу
> можно будет _попытаться_ установить оба пакета сразу и
> тут же обломаться из-за /usr/bin/esd, наличествующего и там,
> и там.
Да, именно так.

> Так что Conflicts: нужен, осталось выяснить,
> как будет называться пакет, содержащий esound'овский
> /usr/bin/esd (не esound -- мы уже договорились, как я понимаю).
Помнится, в похожем случае с cdrecord, которому на смену пришёл dvdrecord, в репозитории появился пакет cdrecord-classic... Не то чтобы мне нравилась эта идея, но прецедент.

> Ожидаю также увидеть в таком пакете Conflicts: pulseaudio-daemon
Тут не согласен. Почему, собственно, именно -daemon? А если в каком-нибудь лучезарном или не очень будущем появится-таки отдельный pulseaudio-esd? Почему бы в нужном пакете из pulseaudio не вставить конфликт на esound-старый?

(что навело на мысли о том, что такие конфликты можно вычислять автоматически - по предоставлению файлов с одинаковым именем, но разным содержанием... но это другая сказка)

Created attachment 3074 [details]
pulseaudio.spec

Предлагаю сделать все ж pulseaudio-esd как в прилагаемом спеке.

pulseaudio-esd как самостоятельная сущность, не требующая
pulseaudio-daemon, не появится никогда -- собственно,
в предлагаемом aris@ спеке это явно выражено.
я уж не говорю о том, что собственно _модули_ pulseaudio,
как раз и обеспечивающие нужный функционал, так и остались
в pulseaudio-daemon.
Бишь, при установке pulseaudio-esd поставится pulseuaudio-daemon,
что сейчас, что в некоем будущем -- чего тогда огороды городить ?

Я о другом варианте. О возможности присутствия pulseaudio-daemon _и_ esound при отсутствии pulseaudio-esd. Правда, одновременная работа esound и pulseaudio-daemon - это что-то из разряда фантастики... Ладно, не знаю, в общем. Мне всё равно :)

> Я о другом варианте. О возможности присутствия pulseaudio-daemon _и_ esound
> при отсутствии pulseaudio-esd
эээ. ну, как бы такой вариант не невозможен, да.
но тогда: если оставлять esd-related модули в pulseaudio-daemon (как предлагает aris@) -- они грузятся при старте из дефолтного конфига pulse, создавая
при этом unix socket /tmp/.esd-<uid>/socket -- с понятными последствиями
в виде драчки за тапки между esound-esd и pulse-daemon.
Уносить же модули из pulseaudio-daemon означает выкусывать функционал, который
там был и так (не все программы, выводящие звук через esd непременно хотят
наличия /usr/bin/esd, удовлетворяясь имеющимся сокетом).
объезжать ещё и это, выдумывая дополнительный уровень req/prov мне что-то
совсем неохота.
в общем, предлагаю считать комбинацию старый-esound + pulse-без-esound
выдуманной, ненужной, запрещённой и т.п.

Может быть вообще вынести esound из системы, оставив только pulseaudio ?

Указать в pulseaudio Provides esound и Obsoletes esound.

Будет счастье.

pulseaudio-daemon-0.9.13-alt2
провайдит esound и конфликтует с esound-daemon.
давайте уже сделаем наконец. см.тж. #17998

sorta fixed

Я, конечно, понимаю, что вроде бы как говорили про esound-daemon. Но на данный момент в Сизифе вот уже два месяца как лежит пакет esd вместо esound. Честно говоря, ради того, чтобы подойти под конфликт с pulseaudio-daemon, снова переименовывать пакет совсем не хочется. Можно мы сделаем s/esound-daemon/esd/ в спеке pulseaudio?

Сорри, я тормоз.