pulseaudio умеет прикидываться esound (см. man esdcompat из пакета pulseaudio-daemon). Хотелось бы иметь возможность использовать вместо безнадежно устаревшего, больного и неподдерживаемого esound -- pulseaudio.
собственно, что в обсуждаемом пакете этому препятствует ? дефолтный конфиг нужный модуль грузит. осталось всего ничего -- пересобрать 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?
Сорри, я тормоз.
