Нужна помощь с написанием ebuild'a для модуля pulseaudio

Завести PULSE_VER и обновлять его, если надо.

100% рабочий вариант(и пока, в отсутствии src_fetch, увы единственный). В src_unpack уже действует network sandbox, поэтому запихать скачивание туда не получится. Хм, проверил у себя на тестовом ебилде - нет, network sandbox в src_unpack не действует(раньше он игнорировался только для unpack-функций в eclass-ах). Видимо это связано с тем, что src_fetch не успели вытащить в отдельную функцию и подобное ограничение слишком многое ломало.

Тогда можно формировать SRC_URI для установленной в системе версии pulseaudio придется в ебилде. Узнать текущую версию установленного пакета можно с помощью best_version

По второму вопросу, увы, не подскажу - тоже не шибко знаток pulseaudio. Могу сказать только что я сталкивался с подобным софтом - который требует именно исходников, а не заголовочных файлов, и по опыту своему могу сказать что это хреновый дизайн. А вот чего именно - самого такого софта или того, от которого он зависит - это уже более интересный(и неоднозначный) вопрос...

P.S. Блин, сразу чувствуется что мало занимаюсь разработкой, отстал я от новомодных веяний, не всё уже помню

Благодарю, как то best_version выпал из поля зрения.
Понимаю, что из разряда фантастики, но мало ли - а можно каким нибудь хитрым трюком дернуть ebuild <path to pulseaudio ebuild> configure а потом из его WORKDIR вытащить готовый конфиг? По моему это единственный способ получить идентичный config.h.
Или будет логичнее забить, т.к. разработчики должны озаботиться этим, как например pulseaudio-modules-bt?

можно каким нибудь хитрым трюком дернуть ebuild <path to pulseaudio ebuild> configure а потом из его WORKDIR вытащить готовый конфиг?

В общем случае нельзя. Особенно если планируешь использовать ебилд где-то кроме локалхоста. Если на QA совсем насрать и мы обсуждаем техническую возможность подобного изврата - то можно попробовать временно переопределить PORTAGE_TMPDIR(на такую, что содержит WORKDIR текущего ебилда, потому что иначе sandbox будет против), дернуть вызов ebuild из ебилда(будет ли это вообще работать и не сломается ли всё к хренам - хз, не пробовал).

В процессе вызова утилита ebuild может, ясен пень, полезть куда-то, куда sandbox не даст - это можно густо обмазать соответствующими костылями^W функциями. Ну или тупо отключить sandbox, см. пункт выше про планирование использования где-то кроме локалхоста.

Результирующий ебилд-франкенштейн лучше не показывать никому из действующих членов Gentoo QA team, дабы они не схватили инфаркт(или наоборот, не начали ржать как сумасшедшие). Я, как бывший член этой команды, тоже пожалуй воздержусь.

Согласен, что это тот еще изврат и неправильный путь. Лучше написать разрабам.
Еще раз спасибо, вопросов боле не имею.