On Sun, Nov 04, 2007 at 05:24:40PM +0300, Alexey Tourbin wrote:
> > А я ещё ничего и не заливал.
> Тогда ладно.  Пока можно без справки. :)

Как там прогрессирует распил mono?

У меня готова или почти готова новая версия rpm-build-mono.
В ней решены почти все проблемы, которые можно решить на данном
этапе развития относительно доступными средствами.

Тут такая тонкость, что сразу после того, как эта версия rpm-build-mono
попадёт в сизиф, желательно сразу же собрать с ней mono.  Раньше этого
сборка любого моновского пакета даст анметы (которые, впрочем,
рассосутся при прохождении нового mono).  В остальном совместимость
сохранена -- то есть не придётся сразу же пересобирать все имеющиеся
моновские пакеты.

По прежнему просьба положить /usr/bin/monodis в какой-нибудь самый
базовый моновский пакет, а может и отпилить отдельно в пакет с нехитрым
названием monodis (правда, тогда ещё и придётся отпилить libmono).

Я посмотрел как собраны некоторые моновские пакеты.  Есть вот какая
претензия: не нужно делать отдельно напр. libgtk-sharp2-devel пакета,
в котором единcтвенное что есть это *.pc файлы.  Точнее, не надо
класть *.pc файлы в отдельный *-devel пакет, если правильное
использование *.pc файла не дает ГАРАНТИРОВАННОГО использования
каких-либо ДРУГИХ файлов из этого пакета (типа include'ов и
симлинка для линковки в более типичном случае).

Иначе buildreq не обнаружит зависимость на такие пакеты, т.к.
*.pc файлы сами по себе игнорируются buildreq'ом.  А если buildreq
не обнаруживает зависимости то это очень плохо с точки зрения технологии
разработки.

Ещё претензия по сборке mono: убрать всё зависимости, выставленные
вручную.  Например, сейчас mono требует libicu.  Я так и не нашёл,
где там зашита зависимость на libuci.  Это наверное просто наколка.
В общем, лучшее, что может сделать maintainer по части зависимостей --
это ПРОСТО запускать buildreq.  Всё остальное должно волшебным образом
получиться автоматически, а если что-то не получается, значит надо
фиксить сборочную среду/технологию сборки.  Таково мое понимание
технологичности разработки пакетов.