13863 2008-01-03 23:50:22 +0300 Неправильно, что mono требует devel-пакет 2009-07-01 08:48:49 +0400 1 1 4 Development Sisyphus mono unstable all Linux CLOSED FIXED P2 normal --- 1 lav cas cas ktirf serjigva wrar qa-sisyphus oldest_to_newest 60323 0 lav 2008-01-03 23:50:38 +0300 Надо бы избавиться от такой зависимости. $ sudo rpm -e glib2-devel error: removing these packages would break dependencies: pkgconfig(glib-2.0) is needed by mono-1.2.6-alt1 pkgconfig(gthread-2.0) is needed by mono-1.2.6-alt1 60331 1 shaba 2008-01-04 05:19:35 +0300 *** Bug 13864 has been marked as a duplicate of this bug. *** 60333 2 shaba 2008-01-04 05:20:24 +0300 *** Bug 13865 has been marked as a duplicate of this bug. *** 60342 3 at 2008-01-04 16:00:02 +0300 От этой зависимости нельзя избавиться, она происходит через файл mono.pc, который одновременно находится сразу в двух пакетах (mono и libmono-devel). Вот подробное письмо в devel@ по этому поводу. http://lists.altlinux.org/pipermail/devel/2007-November/066468.html 60524 4 lav 2008-01-07 16:10:01 +0300 Нет ничего невозможного. Использовать mono без установки кучи devel-пакетов должно быть возможно. Давайте просто определимся, что для этого надо поменять. Очевидно, что использовать mono.pc для "обнаружения mono" является некорректным, и это поведение пакетов, если оно столь повсеместно, необходимо исправить единым рецептом. 60526 5 lav 2008-01-07 16:13:20 +0300 Главное, что пока непонятно, у каких пакетов вызывает проблему наличие mono.pc только в libmono-devel. 60734 6 lav 2008-01-09 18:28:06 +0300 А кто может уделить время обсуждению и созданию решения по данной проблеме? 60738 7 at 2008-01-09 19:03:55 +0300 Большая часть моновских пакетов использует 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. 60739 8 dottedmag 2008-01-09 19:07:22 +0300 Дело не в занимаемом месте, а в семантике. > напротив, понятно, у каких пакетов отсутствие mono.pc вызовет проблемы при сборке. Запатчить их, и всего дел. 60742 9 at 2008-01-09 19:15:22 +0300 На самом деле есть УЖАСНЫЙ ХАК который может разрулить эту проблему в пакете mono положить /usr/share/pkgconfig/mono.pc без зависимостей а в пакете libmono-devel положить %_libdir/pkgconfig/mono.pc c зависимостями При этом mono.pc из libdir будет когда надо перекрывать mono.pc из /usr/share. Но этот хак столь ужасен что я охотнее запаковал одинаковый mono.pc в два пакета. Короче, мне опять приходится объяснять, что я хорошо подумал, прежде чем... 60743 10 at 2008-01-09 19:19:58 +0300 Там проблема, которую мы здесь обуждаем, является в таком случае следствием. А проблема тогда в семантике 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. 60751 11 dottedmag 2008-01-09 19:37:56 +0300 Мда, похоже, что и правда лечение было бы хуже болезни. Надо деИказе голову вправлять сначала :( 60755 12 at 2008-01-09 20:44:58 +0300 Есть общая проблема с семантикой зависимостей в *.pc файлах, я об этом несколько раз писал. Например здесь: http://lists.altlinux.org/pipermail/devel/2007-September/063330.html 60756 13 at 2008-01-09 20:58:41 +0300 Похожая известная мне проблема -- пакет 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 просто так "подчистить" уже нельзя. 60773 14 lav 2008-01-09 23:01:34 +0300 (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. 60774 15 at 2008-01-09 23:44:10 +0300 Виталий, этим пакетам для сборки не нужен 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. 60775 16 at 2008-01-10 00:04:09 +0300 Проблема слишком плохая. В новом релизе rpm-build, которого пока нет в сизифе, я ужесточил правила генерации внутренних зависимостей между подпакетами. Если собрать mono новым rpm-build, то через клаузу 'Libs: -lmono' в mono.pc у пакета mono появтся зависимость на %_libdir/libmono.so -> libmono-devel. Шульмовать становится всё труднее. Хорошего решения я пока не вижу. 60776 17 sin 2008-01-10 00:27:31 +0300 (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 лучше, если он пока так сделан? 60778 18 lav 2008-01-10 00:48:34 +0300 (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. 60781 19 at 2008-01-10 01:10:09 +0300 sin: mono.pc _означает_ две разные вещи: 1) что в системе имеется базовый mono рантайм; 2) как слинковаться с библиотекой libmono. Больше он ничего не означает. Линковаться с библиотекой libmono-devel приходится относительно редко, чаще приходится проверять наличие mono-рантайма. Вообще, лучше считать, что libmono-devel не имеет никакого отношения к mono, это два _разных_ смысла, которые означает mono.pc. Поэтому не надо ничего никуда прибивать гвоздями. mono.pc должен лежать в том же пакете, с файлами из которого он одновременно используется. Поскольку у mono.pc есть два разных смысла, то он должен лежать в двух пакетах. Правда, это червато левыми зависимостям, потому что имеет место пересечение (или объединение) смыслов. Но это пересечение смыслов является общепринятой практикой в моновских пакетов. Решение проблемы в идеале должно состоять в том, чтобы создать отдельные *.pc файлы для проверки mono-рантайма и для линковки с libmono. Но это идеальное решение идёт вразрез с общепринятой практикой, то есть это в некотором смысле будет мартышкин труд. 60783 20 at 2008-01-10 01:33:10 +0300 Виталий, 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 имеет определённую семантическую нагрузку, на которую мы едва ли в силах повлиять. 60788 21 lav 2008-01-10 02:07:24 +0300 (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 не используется в Сизифе. 60789 22 at 2008-01-10 02:12:25 +0300 В моем последнем рассуждении есть фактическая неточность. Если преместить 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 в этой топологии один из самых маленьких. В общем, спокойной ночи. "Всем вам спокойной ночи!" Ну а дальше вы знаете... 60792 23 at 2008-01-10 02:35:50 +0300 Возможен ещё один хак: 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). Как красиво сделать подстановку флагов вместо зависимости я вообще-то не знаю. Но конструкция кажется жизнеспособной. 60794 24 lav 2008-01-10 03:47:15 +0300 Всё же вы немного умничаете, с этими "сематнические констрейнты" и "непозитории". Я понимаю что хочется стройности, но пока что всё началось с того, что mono требовал -devel-пакет :) Что насчёт моего предложения _просто_ убрать зависимость на glib2 из mono.pc? И для мифических пакетов, которым это понадобиться, сделать libmono.pc в mono-devel? 60797 25 at 2008-01-10 04:46:43 +0300 Я умничаю не немного, а по полной программе, практически с размахом, наверное из-за своего непомерного самомнения. Результаты 1 - 50 из примерно 234 000 для semantic constraints. Что до отдельного libmono.pc, то не знаю. Подумаю ещё. Пусть пока побудет как есть. 60801 26 sin 2008-01-10 07:29:03 +0300 (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 на текущий момент не разрешимы. Тем более, что при этом пропадают расхождения между семантическими и топологическими ограничениями. 60802 27 sin 2008-01-10 07:55:16 +0300 (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-подпакеты. В общем, недочищенных хвостов тут ещё очень много. 60805 28 ildar 2008-01-10 09:28:19 +0300 Евгений, Вы не обижайтесь, но с недавних пор Виталий "в теме", а Вы - ещё нет. (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 на текущий > момент не разрешимы. Тем более, что при этом пропадают расхождения между > семантическими и топологическими ограничениями. СтОит отделять мухи от котлет. Даже если последние чем-то напоминают первые. 60806 29 ildar 2008-01-10 09:47:26 +0300 (In reply to comment #24) > Что насчёт моего предложения _просто_ убрать зависимость на glib2 из mono.pc? > И для мифических пакетов, которым это понадобиться, сделать libmono.pc в > mono-devel? Я склоняюсь к здравому предложению Виталия и разделить libmono.pc и mono.pc . То немногое, что нужно запатчить, не должно долго сопротивляться. Тем не менее, как человеку, наиболее полно осознающему проблему, рекомендую Алексею не спешить с решением. 60816 30 lav 2008-01-10 10:45:09 +0300 Мне всё больше кажется, что это такая ошибка апстрима, которую надо просто исправить, и самое ясное, когда по mono.pc ищется mono executable, а по libmono.pc - то, что необходимо для сборки с libmono.so Собственно, бага в апстриме-то висит? :) 60821 31 ildar 2008-01-10 11:08:51 +0300 (In reply to comment #30) > Мне всё больше кажется, что это такая ошибка апстрима, которую надо просто > исправить, и самое ясное, когда по mono.pc ищется mono executable, > а по libmono.pc - то, что необходимо для сборки с libmono.so > Собственно, бага в апстриме-то висит? Полагаю, мы её ещё недостаточно осознали, чтобы повесить. 60883 32 sin 2008-01-11 08:50:50 +0300 (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 дописать... 94000 33 repository-robot 2009-07-01 08:48:49 +0400 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)