Прошу вынести конфигурацию в отдельный подпакет для того, чтобы параллельно с дефолтной полной конфигурацией иметь возможность запаковать что-нибудь в духе http://freeswitch.ru/wiki/minimal Разные конфигурации должны как минимум конфликтовать друг с другом. Но лучше было бы задействовать альтернативы и выбирать одну интересующую из нескольких установленных.
я мог бы положить примеры конфигов в документацию -- это всё.
Почему? Лень или есть более серьезные причины? Если я сделаю это изменение у себя в git, оно будет втянуто?
я не хочу устраивать из фрисвича астериск. конфиг, подобный показанному по ссылке, можно было бы просто положить руками на место искоробочного -- никуда он потом не денется. можно было бы также рассмотреть вариант с помещением в пакет нескольких конфигов верхнего уровня и каким-либо ненапряжным переключателем между ними, с дефолтом на то, что есть. делать же все эти безумные конфликтующие пакеты с конфигами я не стану.
Мне не очень нравится идея класть этот конфиг руками, потому что меня посещала мысль сделать специализированное решение (для call-центра, например) на alt+freeswitch средствами mkimage - и в этом случае опакеченная конфигурация была бы кстати. Идея с фиксированным числом возможных конфигураций тоже не очень удобна необходимостью на каждый чих идти на поклон к майнтейнеру, но все же лучше, чем ничего. Какой переключатель будет ненапряжным? control?
идея с открытым списком конфликтующих между собой пакетов конфигураций просто не работает. применительно к намерению собирать нечто с помощью mkimage наиболее ненапряжным (для всех сторон) будет заполнение нынешних конфигов нужным содержимым из image-scripts.d, без всех этих плясок с упаковкой незнамо чего.
впрочем, есть ещё вариант: дописать (средствами инсталлера либо mkimage) в /etc/sysconfig/freeswitch FSOPTIONS='-conf /path/to/alternate/configs' таким образом, нет ни малейшей нужды убеждать кого-то в чём-то.
*** Bug 24886 has been marked as a duplicate of this bug. ***
(В ответ на комментарий №3) > я не хочу устраивать из фрисвича астериск. > конфиг, подобный показанному по ссылке, можно было бы просто > положить руками на место искоробочного -- никуда он потом > не денется. > можно было бы также рассмотреть вариант с помещением > в пакет нескольких конфигов верхнего уровня и каким-либо > ненапряжным переключателем между ними, с дефолтом на то, что есть. > делать же все эти безумные конфликтующие пакеты с конфигами я не стану. Предложенные варианты, лично мне не нравятся. 1. Просто класть конфиг руками не подходит, т.к. а) остается вся другая структура конфигов и если делаешь кастомное решение то не хочется её придерживаться. Приходится просто все удалять. Но при обновлении несуществующие файлы создадутся опять и получается "каша" б) просто положить руками тоже не подходит, т.к. не дистрибутивно. Хочется поставил пакет и все. 2. Как быть когда конфиги редактируются через GUI? С текущей структурой еще больше "каша" получается. Еще и права нужно исправлять. 3. Предложение перенести конфиг и указывать его через FSOPTIONS='-conf /path/to/alternate/configs' тоже не красиво, т.к. старые конфиги остаются и сбивают. Это заранее разложенная грабля. В случае с GUI можно конфиги размещать где-то в /var/ куда может писать вебсервер, а /etc/freeswitch будет ссылка. И все понятно сразу. Несколько пакетов с разными конфигурациями видятся хорошим предложением и не понятно почему поддерживать конфликты является безумно.
> непонятно почему поддерживать конфликты является безумно. потому что с добавлением N+1-го пакета с конфигами придётся поересобирать их все одной пачкой, новый и N предыдущих, для того, чтобы проставить conflicts на вновь появившийся, с вытекающими отсюда накладными расходами. Избавиться от необходимости указывать conflicts очевидно легко, разложив всё по разным путям, с указанием в /e/s/freeswitch актуальной директории. Довод о том, что оставшиеся дефолтные конфиги 'сбивают' или что-то становится непонятным -- нуу, life sucks and then you die.
(In reply to comment #9) > > непонятно почему поддерживать конфликты является безумно. > потому что с добавлением N+1-го пакета с конфигами придётся > поересобирать их все одной пачкой, новый и N предыдущих, > для того, чтобы проставить conflicts на вновь появившийся alternatives?
Вынес конфигурацию из пакета.