ALT Linux Bugzilla – #13863

*** Bug 13864 has been marked as a duplicate of this bug. ***

*** Bug 13865 has been marked as a duplicate of this bug. ***

От этой зависимости нельзя избавиться, она происходит через файл mono.pc,
который одновременно находится сразу в двух пакетах (mono и libmono-devel).

Вот подробное письмо в devel@ по этому поводу.
http://lists.altlinux.org/pipermail/devel/2007-November/066468.html

Нет ничего невозможного.
Использовать mono без установки кучи devel-пакетов должно быть возможно.
Давайте просто определимся, что для этого надо поменять.
Очевидно, что использовать mono.pc для "обнаружения mono" является 
некорректным, и это поведение пакетов, если оно столь повсеместно,
необходимо исправить единым рецептом.

Главное, что пока непонятно, у каких пакетов вызывает проблему наличие
mono.pc только в libmono-devel.

А кто может уделить время обсуждению и созданию решения по данной проблеме?

Большая часть моновских пакетов использует mono.pc для определения присутствия
mono рантайм.  При этом использование mono.pc автоматически требует glib2-devel
-- если насильно игнорировать эту зависимость, то pkg-config будет считать, что
mono.pc "битый".

Главное, что не "непонятно", а, напротив, понятно, у каких пакетов отсутствие
mono.pc вызовет проблемы при сборке.  Таких пакетов не меньше десяти, читайте
рассылку devel@. 
http://lists.altlinux.ru/pipermail/devel/2007-November/066467.html

Виталий, то, что кажется вам "данной проблемой", на самом деле является
компромиссными решением.  Насчёт "кучи devel-пакетов" Вы явно преувеличиваете --
glib2 занимает 0.5M, а mono -- 30M.

Дело не в занимаемом месте, а в семантике.

> напротив, понятно, у каких пакетов отсутствие mono.pc вызовет проблемы при 
сборке.

Запатчить их, и всего дел.

На самом деле есть УЖАСНЫЙ ХАК который может разрулить эту проблему
в пакете mono положить /usr/share/pkgconfig/mono.pc без зависимостей
а в пакете libmono-devel положить %_libdir/pkgconfig/mono.pc c зависимостями

При этом mono.pc из libdir будет когда надо перекрывать mono.pc из /usr/share.
Но этот хак столь ужасен что я охотнее запаковал одинаковый mono.pc в два пакета.

Короче, мне опять приходится объяснять, что я хорошо подумал, прежде чем...

Там проблема, которую мы здесь обуждаем, является в таком случае следствием.
А проблема тогда в семантике mono.pc файла -- он используется для двух разных
вещей: 1) для линковки с libmono, для чего нужно glib2-devel, потому что в
хедерах libmono есть инклюды из glib2 и значит в cflags НУЖНО добавить
-I/usr/include/glib-2.0; то есть никак нельзя убить glib2 из mono.pc; 2) для
обнаружения присутствия mono-рантайма.

Следствием такой семантики mono.pc является проблема в зависимостях -- в рантайм
"пробливается" devel-пакет.

Запатчить все эти пакеты -- во первых, нужен желающий.  Во-вторых, это мартышкин
труд.  Все используют mono.pc как для обнаружения рантайма, так и для линковки с
libmono.

Мда, похоже, что и правда лечение было бы хуже болезни. Надо деИказе голову 
вправлять сначала :(

Есть общая проблема с семантикой зависимостей в *.pc файлах, я об этом несколько
раз писал.  Например здесь:
http://lists.altlinux.org/pipermail/devel/2007-September/063330.html

Похожая известная мне проблема -- пакет gnome-doc-utils требует
pkgconfig(libxml-2.0) -> libxml2-devel.  Пакет gnome-doc-utils является noarch
пакетом и по смыслу никак не должен требовать libxml2-devel!  На самом деле он
требует /usr/bin/xmllint, который отпилен от libxml2 в пакет xml-utils.  Но на
уровне зависимостей в *.pc файлах эту тонкость никак передать нельзя.

В gnome-doc-utils из *.pc файла можно просто удалить зависиомсть на libxml-2.0
(и добавить в spec "правильную" зависимость на /usr/bin/xmllint).  А вот mono.pc
просто так "подчистить" уже нельзя.

(In reply to comment #7)
> отсутствие mono.pc вызовет проблемы при сборке.  Таких пакетов не меньше 
десяти, читайте рассылку devel@. 
> http://lists.altlinux.ru/pipermail/devel/2007-November/066467.html
Я уже читал это письмо не раз. И в упор не понимаю что вы хотите сообщить.
Пишете "вызовет проблемы при сборке". А кто против - есть mono-devel, в нём 
есть mono.pc

Взять тот же cdcollect из списка. Да, без mono.pc он не соберётся. Но ведь без 
mono.pc он отлично работает.
Повторю вопрос ещё раз: есть ли информация, какие пакеты  используют 
mono.pc "для обнаружения присутствия mono-рантайма.", и у них вызовет проблему 
то, что mono.pc будет лежать в mono-devel (то есть отсутствовать в системе) ?

> Виталий, то, что кажется вам "данной проблемой", на самом деле является
> компромиссными решением.  Насчёт "кучи devel-пакетов" Вы явно
Согласен, решение компромиссное. Осталось понять суть проблемы.

> преувеличиваете -- glib2 занимает 0.5M, а mono -- 30M.
Да, я ошибся, мне показалось, что glib2-devel тянет обязательно glibc-devel.

Виталий, этим пакетам для сборки не нужен mono-devel.  Им нужен mono-рантайм.
В пакете mono-devel лежит что-то ещё, что для сборки не нужно.

Общее правило состоит в том, что файл mono.pc должен находиться в том пакете, в
котором лежат файлы, совместно с которыми он используется.  Можно считать, что
семантика runtime probe означает, что mono.pc должен находиться в том же пакете,
что и /usr/bin/mono и /usr/lib/.../mscorlib.dll.  Я думаю, что не нужно его
искусственно перекладывать в mono-devel.

Вот типичный кусок кода из configure.in моновских пакетов

MONO_REQUIRED_VERSION=1.0
PKG_CHECK_MODULES(MONO_DEPENDENCY, mono >= $MONO_REQUIRED_VERSION,
has_mono=true, has_mono=false)

Здесь определяется, есть в системе mono или нет.  Это базовая проверка.  Если
mono-рантайм установлен у мы можем запускать mono-программы, то она должна
выполняться.

$ grep Description /usr/lib/pkgconfig/mono.pc
Description: Mono Runtime
$

Для сборки mono пакетов, как правило, нужны только 1) базовый mono-рантайм; 2)
компилятор mono-mcs; и 3) дополнительные *.dll библиотеки, если они требуются
для сборки.  Отдельного *-devel компонента для сборки у mono в принципе особо не
существует, т.к. все *.dll библиотеки содержат полную метаинформацию о себе (то
есть типа хедеры и прототипы зашиты внутри самих *.dll файлов, и их можно
посмотреть с помощью /usr/bin/monodis).

Так что проблема тут вовсе не в том, что mono.pc лежит пакете mono а не
mono-devel.
Проблема в том, что mono.pc используется в двух разных случайх, и поэтому из
него нельзя убрать зависимость на glib2-devel.

Проблема слишком плохая.  В новом релизе rpm-build, которого пока нет в сизифе,
я ужесточил правила генерации внутренних зависимостей между подпакетами.
Если собрать mono новым rpm-build, то через клаузу 'Libs: -lmono' в mono.pc 
у пакета mono появтся зависимость на %_libdir/libmono.so -> libmono-devel.

Шульмовать становится всё труднее.
Хорошего решения я пока не вижу.

(In reply to comment #14)
Я просмотрел зависимости libgtk-sharp2 и тоже не нашёл явных зависимотей на
mono.pc. Я так понимаю, что для сборки достаточно поставить сборочную
зависимость на libmono-devel.

Вероятно способ избавления от этих зависимостей может оказаться даже несколько
проще, чем может показаться на первый взгляд.

(In reply to comment #15)
То есть получается, что вместо указания зависимости на mono-devel или
libmono-devel, при сборке соотвествующих пакетов, где используется вот таким вот
образом реализованный вариант поиска Mono Runtime с помощью autotools, мы
организуем зависимость этого самого рантайма от devel-пакетов...?!

Весьма неровный компромис. Вообще не вижу проблемы для всех пакетов, которые
используют во время сборки аутотулзовый поиск моно рантайма, прибить зависимость
на соотвествующий девел-пакет. Насколько я понимаю все текущие девел-зависимости
именно так и работают. И не важно при этом зависимость это присутсвующего в
системе объекта или нет.

ИМХО, сборочная зависимость на десяток файлов из libmono-devel, который ни от
чего не зависит кроме pkg-config, rpm и того, от чего зависит mono.pc, для
пакетов использующих autotools, более разумный компромис, чем дублирование
mono.pc и создавание зависимости рантайма от совершенно ненужных сторонних
devel-пакетов.

Без необходимости же зависеть Mono Runtime от devel-пакетов Glib никаким
перенесом mono.pc в дополнительные пакеты не добиться. В этом плане текущее
решение совершенно избыточно.

Есть тут конечно особенность, что для самостоятельной сборки сторонних проектов
потребуется неявно ставить libmono-devel. Но точно также совершенно неявно
требуется для сборки с использованием libGL пакет libmesa-devel. Да, в
libmesa-devel есть нужные файлы, а в libmono-devel казалось бы нет. Но так ли
это? Ведь для сборки требуются те же пакеты, которые ставятся сейчас зачем-то
пользователю. Вероятно разработчику они всё же нужнее. Давайте не будет
переносить проблемы разработчиков пользователям. В конце концом если ./configure
обламывается на этапе поиска -lGL, и нужно поставить libmesa-devel, то чем mono
лучше, если он пока так сделан?

(In reply to comment #15)
> Виталий, этим пакетам для сборки не нужен mono-devel.  Им нужен 
mono-рантайм.
и mono.pc, который есть в mono-devel.
> В пакете mono-devel лежит что-то ещё, что для сборки не нужно.
Мне всё равно что ещё есть в этом пакете :)

> Общее правило состоит в том, что файл mono.pc должен находиться в том 
пакете, в
> котором лежат файлы, совместно с которыми он используется.  Можно считать,
Как писал Алексей Турбин, "Файлы *.pc, как правило, должны входить в -devel 
пакеты.". Я с ним согласен.


> семантика runtime probe означает, что mono.pc должен находиться в том же 
пакете,
> что и /usr/bin/mono и /usr/lib/.../mscorlib.dll.  Я думаю, что не нужно его
> искусственно перекладывать в mono-devel.
Искусственно ваше правило, по которому вы предлагаете pc-файл, который 
_всегда_ должен быть в -devel пакете, запихнуть к runtime.

> для сборки.  Отдельного *-devel компонента для сборки у mono в принципе 
особо не существует,
Но пакет mono-devel есть :)

> Так что проблема тут вовсе не в том, что mono.pc лежит пакете mono а не
> mono-devel.
> Проблема в том, что mono.pc используется в двух разных случайх, и поэтому из
> него нельзя убрать зависимость на glib2-devel.
Проблема в том, что вы пока не сообщили как mono.pc используется в случаях, не 
относящихся к сборке пакета. А если он используется только при сборке, его 
место - в mono-devel.

sin: mono.pc _означает_ две разные вещи: 1) что в системе имеется базовый mono
рантайм; 2) как слинковаться с библиотекой libmono.  Больше он ничего не
означает.  Линковаться с библиотекой libmono-devel приходится относительно
редко, чаще приходится проверять наличие mono-рантайма.  Вообще, лучше считать,
что libmono-devel не имеет никакого отношения к mono, это два _разных_ смысла,
которые означает mono.pc.

Поэтому не надо ничего никуда прибивать гвоздями.  mono.pc должен лежать в том
же пакете, с файлами из которого он одновременно используется.  Поскольку у
mono.pc есть два разных смысла, то он должен лежать в двух пакетах.  Правда, это
червато левыми зависимостям, потому что имеет место пересечение (или
объединение) смыслов.  Но это пересечение смыслов является общепринятой
практикой в моновских пакетов.  Решение проблемы в идеале должно состоять в том,
чтобы создать отдельные *.pc файлы для проверки mono-рантайма и для линковки с
libmono.  Но это идеальное решение идёт вразрез с общепринятой практикой, то
есть это в некотором смысле будет мартышкин труд.

Виталий, mono.pc может самостоятельно и не использоваться в рантайме, но это не
повод переместить его в mono-devel.  Мое правило состоит не только в том, что
*.pc файлы должны, как правило, находиться в *-devel пакетах.  Другое мое
правило -- *.pc файл должен лежать в том же пакете, с файлами из которого он
одновременно используется (по назначению).  Это придаёт *.pc файлу правильную
семантическую нагрузку -- если *.pc файл используется для обнаружения
mono-рантайма, то он должен лежать в пакете с моно-рантаймом.  Это не
противоречит первому правилу: как правило, *.pc файлы используются для линковки
с библиотеками и поэтому в таких случаях лежат в lib%name-devel пакетах.

Виталий, суть проблемы на самом деле в том, что ПО ОПРЕДЕЛЁННОЙ ПРИЧИНЕ из
mono.pc нельзя удалить зависимость на glib2-devel.  В остальном mono.pc в пакете
mono находится на своём месте.

Если переместить mono.pc из пакета mono в пакет mono-devel, то придётся в
большую часть моновских пакетов вручную вписывать BuildRequires: mono-devel. 
Эту зависимость не обнаружит /usr/bin/buildreq, потому НА САМОМ ДЕЛЕ пакет
mono-devel (кроме *.pc файла) никак не используется при сборке этих пакетов.  То
 есть сломается большая половина моновских пакетов, что мы уже наблюдали.  Это
как раз и означает, что файл mono.pc имеет определённую семантическую нагрузку,
на которую мы едва ли в силах повлиять.

(In reply to comment #20)
...
> Если переместить mono.pc из пакета mono в пакет mono-devel, то придётся в
> большую часть моновских пакетов вручную вписывать BuildRequires: mono-devel. 
...
> Это как раз и означает, что файл mono.pc имеет определённую семантическую 
нагрузку, на которую мы едва ли в силах повлиять.

Алексей, спасибо за терпеливое объяснение, я осознал проблему.
Нельзя ли всё же подойти к ней с другой стороны:
Я посмотрел, что libmono используется только в monodis, mono-debugger и в 
beagle.
Быть может мы сделаем libmono.pc ?
Конечно, это потребует небольшого изменения в этих пакетах...
Но если вспомнить, как массово заменялся поиск .la-файлов в KDE-программах 
когда-то...
Но изменения не во всех пакетах. monodis сам из пакета mono собирается,
в mono-debugger проверка такая:
mono >= $MONO_REQUIRED_VERSION glib-2.0 >= $GLIB_REQUIRED_VERSION 
то есть нужные библиотеки и так будут найдены.
Ну а beagle вообще не использует флаги из mono.pc, как я увидел (версию 
проверяет, конечно).
Таким образом, реально зависимость на библиотеки в mono.pc не используется в 
Сизифе.

В моем последнем рассуждении есть фактическая неточность.  Если преместить
mono.pc в mono-devel, то сломается несколько меньше (когда всё сломалось,
mono.pc был перемещён в новый пакет libmono-devel).

Но это не менят сути дела -- *.pc файл должен лежать в том же пакете, с файлами
из которого он одновременно используется (по назначению).  Если *.pc файл
используется для компиляции/линковки с библиотекой, то он должен лежать в том же
пакете, в котором лежат хедеры и симлинк на сонейм.  Если он используется для
обнаружения рантайма, то он должен лежать в пакете с рантаймом.  Правильная
группировка файлов даёт правильную семантическую нагрузку подпакетам.

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

Если переложить mono.pc из mono в mono-devel, то buildreq перестанет
обнаруживать сборочную зависимость на mono-devel.  А это очень плохо, это
технологический прокол.  Но он связан с семантическим проколом, с неправильной
группировкой файлов.

Правда, выполняя сематнические констрейнты, мы в данном случае нарушаем
топологические констрейнты -- упорядоченность самих пакетов.  Нарушается
условие, что любой не-*-devel пакет должен быть "меньше" любого *-devel пакета
(то есть установка не-*-devel пакета не должна вытягивать *-devel пакетов). 
Правда, у *-devel пакетов есть своя топология, и glib2-devel в этой топологии
один из самых маленьких.

В общем, спокойной ночи.  "Всем вам спокойной ночи!"  Ну а дальше вы знаете...

Возможен ещё один хак:
1) Убрать из mono.pc зависимость на glib-2.0
2) Вместо этого добавить в mono.pc фактические флаги из glib-2.0
Cflags: ... -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
Libs: ... -lglib-2.0
3) В пакете mono игнорировать зависимости, которые проставляются через Libs
4) В пакете libmono-devel на всякий случай добавить зависимость на glib2-devel
(она также должна проставиться автоматически через Libs: -lglib-2.0).

Как красиво сделать подстановку флагов вместо зависимости я вообще-то не знаю. 
Но конструкция кажется жизнеспособной.

Всё же вы немного умничаете, с этими "сематнические констрейнты" 
и "непозитории". Я понимаю что хочется стройности, но пока что всё началось с 
того, что mono требовал -devel-пакет :)

Что насчёт моего предложения _просто_ убрать зависимость на glib2 из mono.pc?
И для мифических пакетов, которым это понадобиться, сделать libmono.pc в 
mono-devel?

Я умничаю не немного, а по полной программе, практически с размахом, наверное
из-за своего непомерного самомнения.

Результаты 1 - 50 из примерно 234 000 для semantic constraints.

Что до отдельного libmono.pc, то не знаю.  Подумаю ещё.  Пусть пока побудет как
есть.

(In reply to comment #19)
Я готов несколько оспорить 1 пункт о том, что "mono.pc означает, что в системе
имеется базовый mono рантайм". С таким же успехом glib.pc означает, что в
системе имеется библиотека Glib. ИМХО, и то, идругое означает для Autotools, что
в системе имеется сборочный пакет для поддержки рантайма или библиотеки во время
сборки. То, что важных файлов, кроме mono.pc, для Mono Runtime пока нет, ещё не
означает, что они не появятся в будущем. То, что стоит считать, что
libmono-devel не имеет отношение к mono. В этом вопросе я скорее склоняюсь к
мнению, что необходимость вынесения 80кб "заголовочных вайлов" в пакет
зависящий, в основном, только от того, от чего зависит mono.pc, вообще говоря
несколько сомнительна.

В качестве решения я предлагаю вернуть содержимое libmono-devel обратно в
mono-devel. На чём, как я сейчас понимаю, все проблемы решаться сами собой.

(In reply to comment #22)
> В моем последнем рассуждении есть фактическая неточность.  Если преместить
> mono.pc в mono-devel, то сломается несколько меньше (когда всё сломалось,
> mono.pc был перемещён в новый пакет libmono-devel).

Хотелось понять, что действительно сломается. Я так понимаю, что этим "что",
будут те, кто ожидает увидеть заголовочные файлы от Mono Runtime. И связи с этим
снова предлагаю вернуть содержимое libmono-devel обратно в mono-devel. На всякий
случай можно поставить в mono-devel Provides на libmono-devel.

Я думаю, что не стоит разрывать сущность не объекты, которые создают такие
сложные семантические ограничения, которые средствами rpm и build-req на текущий
момент не разрешимы. Тем более, что при этом пропадают расхождения между
семантическими и топологическими ограничениями.

(In reply to comment #26)
На самом деле, конечно, говорить об Autotools в контексте использования mono.pc,
является с моей стороны некоторой небрежностью. Прошу прощения, конечно я имел в
виду pkg-config. Тем не менее, сути вопроса это не меняет - mono.pc, в моём
понимании, означает сборочную подпорку и его, вместе со всем содержимым текущего
libmono-devel, стоит вернуть в mono-devel. Как говорится, не стоит умножать
сущности без необходимости.

Замечу также, что, если решать проблему с переносом сборочных частей mono по
подпакетам, то вероятно стоит сначала локализвать все файлы этих сборочных
частей в mono-devel. Например, /usr/lib/pkgconfig/mono-cairo.pc у нас лежит в
пакете mono, хотя ему самое место в mono-devel. Для многих замкнутых пакетов
вроде monodevelop, такие файлы как monodevelop.pc либо вообще не стоит включать
в пакет, либо вероятно нужно выносить в devel-подпакеты. В общем, недочищенных
хвостов тут ещё очень много.

Евгений,
Вы не обижайтесь, но с недавних пор Виталий "в теме", а Вы - ещё нет.

(In reply to comment #26)
> (In reply to comment #19)
> Я готов несколько оспорить 1 пункт о том, что "mono.pc означает, что в системе
> имеется базовый mono рантайм". С таким же успехом glib.pc означает, что в
> системе имеется библиотека Glib.

Нет. mono.pc означает, что в системе имеется базовый mono рантайм, _которого_
_достаточно_, _чтобы_ _собирать_ _mono-программы_. (При наличии соответствующего
компилятора). Это не так с glib2.

> ИМХО, и то, идругое означает для Autotools, что
> в системе имеется сборочный пакет для поддержки рантайма или библиотеки во время
> сборки. То, что важных файлов, кроме mono.pc, для Mono Runtime пока нет, ещё не
> означает, что они не появятся в будущем.

Не ожидайте *.h, *.so и т.п.

> То, что стоит считать, что
> libmono-devel не имеет отношение к mono.

ни libmono-devel, ни mono-devel к сборке mono-пакетов в общем случае отношения
не имеют. Последний по сути стоило бы назвать mono-develtools, чтобы не вызывать
лишних вопросов и обсуждений, как в этом #13863

> В этом вопросе я скорее склоняюсь к
> мнению, что необходимость вынесения 80кб "заголовочных вайлов" в пакет
> зависящий, в основном, только от того, от чего зависит mono.pc, вообще говоря
> несколько сомнительна.
> 
> В качестве решения я предлагаю вернуть содержимое libmono-devel обратно в
> mono-devel. На чём, как я сейчас понимаю, все проблемы решаться сами собой.

1. не решатся
2. как я писал выше, в общем случае libmono* - вещи совершенно посторонние.

> (In reply to comment #22)
> > В моем последнем рассуждении есть фактическая неточность.  Если преместить
> > mono.pc в mono-devel, то сломается несколько меньше (когда всё сломалось,
> > mono.pc был перемещён в новый пакет libmono-devel).
> 
> Хотелось понять, что действительно сломается. Я так понимаю, что этим "что",
> будут те, кто ожидает увидеть заголовочные файлы от Mono Runtime. И связи с этим
> снова предлагаю вернуть содержимое libmono-devel обратно в mono-devel. На всякий
> случай можно поставить в mono-devel Provides на libmono-devel.

Сломается buildreq %name.spec

> Я думаю, что не стоит разрывать сущность не объекты, которые создают такие
> сложные семантические ограничения, которые средствами rpm и build-req на текущий
> момент не разрешимы. Тем более, что при этом пропадают расхождения между
> семантическими и топологическими ограничениями.

СтОит отделять мухи от котлет. Даже если последние чем-то напоминают первые.

(In reply to comment #24)
> Что насчёт моего предложения _просто_ убрать зависимость на glib2 из mono.pc?
> И для мифических пакетов, которым это понадобиться, сделать libmono.pc в 
> mono-devel?

Я склоняюсь к здравому предложению Виталия и разделить libmono.pc и mono.pc . То
немногое, что нужно запатчить, не должно долго сопротивляться.

Тем не менее, как человеку, наиболее полно осознающему проблему, рекомендую
Алексею не спешить с решением.

Мне всё больше кажется, что это такая ошибка апстрима, которую надо просто 
исправить, и самое ясное, когда по mono.pc ищется mono executable,
а по libmono.pc - то, что необходимо для сборки с libmono.so
Собственно, бага в апстриме-то висит? :)

(In reply to comment #30)
> Мне всё больше кажется, что это такая ошибка апстрима, которую надо просто 
> исправить, и самое ясное, когда по mono.pc ищется mono executable,
> а по libmono.pc - то, что необходимо для сборки с libmono.so
> Собственно, бага в апстриме-то висит? 

Полагаю, мы её ещё недостаточно осознали, чтобы повесить.

(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #19)

Тут вынесен на обсуждение вопрос, ответ на который не является однозначным. И
вот почему.
1) Если исходить из варианта, когда вы рассматриваете строки вида:
MONO_REQUIRED_VERSION=1.0
PKG_CHECK_MODULES(MONO_DEPENDENCY, mono >= $MONO_REQUIRED_VERSION,
has_mono=true, has_mono=false)
как проверку "на базовый mono рантайм, _которого_ _достаточно_, _чтобы_
_собирать_ _mono-программы_. (При наличии соответствующего компилятора)" и
распространяете эту проверку на все без исключения формы проверки наличия Mono
Runtime в системе. В этом случае вы дейсвительно правы.
2) Исходя же из варианта, что вышенаписанные строки из configure.in - это
простая форма проверки наличия Mono Runtime разработчиками, которые полагают что
mono.pc должен располагаться в пакете mono и только. Больше никто mono.pc для
проверки наличия Mono Runtime не использует. К сожалению, так сложилось, что
разработчики Mono не позаботились (хотя я в этом ещё не уверен) о средствах
обнаружения рантайма. Как впрочем не заботятся о средствах обнаружения gcc
разработчики gcc. И этому есть объяснения по крайней мере такое, что Mono - это
кроссплатформенный Framework. В Windows же он устанавливается по всем канонам
этой системые - всю кучу в один каталог, когда наличие и отсутствие mono.pc, как
впрочем как и любого другого файла из Mono, является критерием наличия рантайма
в системе и того самого отпиленного mcs. Исходя из этого варианта я представляю
себе сложившуюся картину несколько иначе. Выглядит она так: разработчики Mono
приложений, ипользующие Autotools, включая основные связки, придумали костыли,
которые им многие успешно подсовывают. В нашем же случае отделение мух от котлет
приводит к тому, что проблемы этих разработчиков начинают всплывать. В попытках
найти решение в текущих рамках, мы создаём свои костыли, которые ничего, кроме
сложностей сборки, пока не доставляют.
 
По поводу утилит разработчика, которые стоит вынести в mono-develtools, хочу
добавить, что это чревато проблемами позже, а может быть и сразу. В ряде случае,
элементы из набора утилит mono-devel могут потребоваться. И, при текущем подходе
разработчики будут по праву ожидать их наличия. Не вижу смысла препятствовать
им, если конечно не взяться за эту проблему в рамках развития самого Mono и его
базового окружения.

> > В качестве решения я предлагаю вернуть содержимое libmono-devel обратно в
> > mono-devel. На чём, как я сейчас понимаю, все проблемы решаться сами собой.
> 
> 1. не решатся

Почему? Я не про все проблемы, а про те, которые приводят к зависимости mono от
не нужных пакетов и ломают текущую сборку, когда mono.pc вынесен в libmono-devel.

> 2. как я писал выше, в общем случае libmono* - вещи совершенно посторонние.

Для задачи сборки и линковки приложений с libmono без необходимости установки
всего фраймфорка, пакет libmono-devel можно оставить, а mono.pc держать
одновременно и в mono-devel, и в libmono-devel.

> > (In reply to comment #22)
> > > В моем последнем рассуждении есть фактическая неточность.  Если преместить
> > > mono.pc в mono-devel, то сломается несколько меньше (когда всё сломалось,
> > > mono.pc был перемещён в новый пакет libmono-devel).
> > 
> > Хотелось понять, что действительно сломается. Я так понимаю, что этим "что",
> > будут те, кто ожидает увидеть заголовочные файлы от Mono Runtime. И связи с этим
> > снова предлагаю вернуть содержимое libmono-devel обратно в mono-devel. На всякий
> > случай можно поставить в mono-devel Provides на libmono-devel.
> 
> Сломается buildreq %name.spec

А сейчас он работает? Тогда, полагаю он не сломается, если переместить mono.pc
из самого mono в mono-devel? Этот костыль для сборки mono-пакетов пока ещё никто
не отменял.

> > Я думаю, что не стоит разрывать сущность не объекты, которые создают такие
> > сложные семантические ограничения, которые средствами rpm и build-req на текущий
> > момент не разрешимы. Тем более, что при этом пропадают расхождения между
> > семантическими и топологическими ограничениями.
> 
> СтОит отделять мухи от котлет. Даже если последние чем-то напоминают первые.


(In reply to comment #29)
> (In reply to comment #24)
> > Что насчёт моего предложения _просто_ убрать зависимость на glib2 из mono.pc?
> > И для мифических пакетов, которым это понадобиться, сделать libmono.pc в 
> > mono-devel?
> 
> Я склоняюсь к здравому предложению Виталия и разделить libmono.pc и mono.pc . То
> немногое, что нужно запатчить, не должно долго сопротивляться.
> 
> Тем не менее, как человеку, наиболее полно осознающему проблему, рекомендую
> Алексею не спешить с решением.

Проблема таким решением, строго говоря, будет может быть даже ухудшена, а не
решена. Исправлять каждый пакет, испольующий Mono Runtime, при таком решении
может превратить сборку в исследование на тему а что же хотели разработчики из
деталей от Mono. Это решение будет работать только если mono.pc будет
предоставлять всё тоже, что и раньше, но без зависимостей от glib-devel. Для
рядовых же пользователей ситуация будет осложнена. И вот чем:
1) пакеты из консоли престанут собираться;
2) как в большинстве дистрибутивов установка mono-devel может не помочь, а о
том, что нужно доставить libmono-devel, нужно или догадаться, и полазить по вики
и рассылкам.

(In reply to comment #30)
> Мне всё больше кажется, что это такая ошибка апстрима, которую надо просто 
> исправить, и самое ясное, когда по mono.pc ищется mono executable,
> а по libmono.pc - то, что необходимо для сборки с libmono.so
> Собственно, бага в апстриме-то висит? :)

Насколько я понял основную проблему, которую решают текущие решения - перенос
библиотеки libmono в отдельный пакет. К сожалению, в этом случае действительно
возникают проблемы. Проблемы эти связаны с тем, что такое отделение, в силу
кросплатформенности решения, приводит к сложностям, которые на текущем этапе
развития самого Mono не приоритетны. Им бы Winforms дописать... 

mono-2.4.2-alt1 -> sisyphus:

* Tue Jun 30 2009 Alexey Shabalin <shaba@altlinux> 2.4.2-alt1

- 2.4.2
- move all pkg-config files (*.pc) to devel packages (ALT#13863)