[devel] mono: распил *-sharp пакетов

[devel] mono: распил *-sharp пакетов

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3009 bytes --]

Напоминаю проблему.  Крайне нежелательна ситуация, когда в *-devel
пакете лежит всего лишь *.pc файл, и штатное использование *.pc
файла в *-devel пакете не предполагает использование каких-либо
других файлов в этом пакете.

buildreq сейчас игнорирует использование *.pc файлов.  Следовательно,
зависимость на такой *-devel пакет, в котором по сути нет ничего кроме
*.pc файла, будет проигнорирована.  Это несколько сомнительно, но в этом
есть свой резон, потому что это енфорсит определённую (правильную)
логику распила пакетов.

Правильная логика распила пакетов такова, что штатное использование
*.pc файла должно приводить к использованию других файлов в пакете.
Например, если это сишная библиотека, то использование *.pc файла
должно впоследствии "трогать" *.h и *.so файлы иэ этого пакета.

В соответствии с этим есть два варианта более правильного распила
*-sharp пакетов.

1) Не отпиливать *-devel пакет вообще.  В *-devel пакете, как правило,
содержится какая-то "метаинформация", которая не нужна для работы
программ, но нужна для сборки других пакетов.  Типичный пример -- *.h
файлы у сишных библиотек.  В моне нет никакой внешней метаинформации,
все *.dll файлы самодостаточны как по рантайму, так и по возможности
линковки с ними.  Значит, нет резона отпиливать *-devel пакет, в который
можно было бы выносить специальные вещи, которые не нужны для рантайма,
но нужны только для сборки.

2) Сохранить *-devel пакеты.  Насколько я понмаю, в моне для линковки
с диелелями есть симлинки которые похожи на *.so симлинки в сишных
*-devel пакетах.  Пример.

$ cat test.cs
class A { public static void Main() {  }}
$ filereq /dev/stdout mcs -pkg:glib-sharp-2.0 test.cs |grep /usr/lib/mono/
/usr/lib/mono/1.0/I18N.Other.dll
/usr/lib/mono/1.0/I18N.dll
/usr/lib/mono/1.0/System.Xml.dll
/usr/lib/mono/1.0/System.dll
/usr/lib/mono/1.0/mcs.exe
/usr/lib/mono/1.0/mcs.exe.config
/usr/lib/mono/1.0/mscorlib.dll
/usr/lib/mono/gac/glib-sharp/2.10.0.0__35e10195dab3c99f/glib-sharp.dll.config
/usr/lib/mono/gtk-sharp-2.0/glib-sharp.dll
/usr/lib/mono/gac/I18N.Other/1.0.5000.0__0738eb9f132ed756/I18N.Other.dll
/usr/lib/mono/gac/I18N/1.0.5000.0__0738eb9f132ed756/I18N.dll
/usr/lib/mono/gac/System.Xml/1.0.5000.0__b77a5c561934e089/System.Xml.dll
/usr/lib/mono/gac/System/1.0.5000.0__b77a5c561934e089/System.dll
/usr/lib/mono/gac/glib-sharp/2.10.0.0__35e10195dab3c99f/glib-sharp.dll
$

То есть линковка с моновскими диелелями идёт не через /usr/lib/mono/gac/
а через специальные симлинки которые указаны в *.pc файлах.  В данном
случае это /usr/lib/mono/gtk-sharp-2.0/glib-sharp.dll.

Поэтому есть возможность переместить эти симлинки в *-devel пакет,
а в основном пакете оставить только GAC ассемблию.  То есть распил
получается примерно такой:

%files
/usr/lib/mono/gac/*

%files devel
%dir /usr/lib/mono/gtk-sharp-2.0
/usr/lib/mono/gtk-sharp-2.0/*.dll

Тогда эти симлинки из *-devel пакета будут вылавливаться buildreq'ом при
линковке с диелелями.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] mono: распил *-sharp пакетов

[Ildar Mulyukov]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

не понимаю, почему это письмо не дошло. Ознакомьтесь.

Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

[-- Attachment #2: Type: message/rfc822, Size: 9419 bytes --]

From: Ildar Mulyukov <ildar@altlinux.ru>
To: devel@lists.altlinux.org
Subject: Re: [devel] rpm-build-mono 1.2
Date: Tue, 06 Nov 2007 11:57:15 +0600
Message-ID: <1194328635l.9963l.0l@ildar.innovations.kz>

On 06.11.2007 03:28:51, Alexey Tourbin wrote:
> 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 не  
> обнаруживает зависимости то это очень плохо с точки зрения технологии  
> разработки.

Это всё очень плохо. Что же делать? Реально для сборки какого-нибудь  
пакета нужны %name.dll (бинарь) и %name.pc для вытаскивания других  
бинарей по зависимостям.
Можно было бы *.pc класть в основной пакет, но в этом случае при  
установке пакета %name будут вытягиваться по зависимости все *-devel, а  
это может быть немалый довесок.

> Ещё претензия по сборке mono: убрать всё зависимости, выставленные  
> вручную.  Например, сейчас mono требует libicu.  Я так и не нашёл,  
> где там зашита зависимость на libuci.  Это наверное просто наколка.

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

Выглядит заманчиво, но я не поведусь ;) Уж я не знаю, что сделали для  
этого за последние полгода - я просто был в оффлайне всё это время. Но:
1. не все используемые внешние библиотеки прописаны в *.dll.config  
(были, и, поручусь, ещё есть)2. (Пока) Нет способа полностью  
автоматизированно выловить директивы использования внешних библиотек в  
коде. (Вам же не приходит в голову прочёсывать C-программу в поисках  
dlopen()?)

В конце замечу, что, Алексей, Вы меня несказанно радуете участием в  
нашей скорбной участи поддержки mono-пакетов ;-) Большое Вам спасибо!

С уважением, Ильдар.
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] mono: распил *-sharp пакетов

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4398 bytes --]

On Sun, Nov 25, 2007 at 08:52:02PM +0600, Ildar Mulyukov wrote:
> >Я посмотрел как собраны некоторые моновские пакеты.  Есть вот какая  
> >претензия: не нужно делать отдельно напр. libgtk-sharp2-devel пакета,  
> >в котором единcтвенное что есть это *.pc файлы.  Точнее, не надо  
> >класть *.pc файлы в отдельный *-devel пакет, если правильное  
> >использование *.pc файла не дает ГАРАНТИРОВАННОГО использования  
> >каких-либо ДРУГИХ файлов из этого пакета (типа include'ов и симлинка  
> >для линковки в более типичном случае).
> >
> >Иначе buildreq не обнаружит зависимость на такие пакеты, т.к. *.pc  
> >файлы сами по себе игнорируются buildreq'ом.  А если buildreq не  
> >обнаруживает зависимости то это очень плохо с точки зрения технологии  
> >разработки.
> 
> Это всё очень плохо. Что же делать? Реально для сборки какого-нибудь  
> пакета нужны %name.dll (бинарь) и %name.pc для вытаскивания других  
> бинарей по зависимостям.
> Можно было бы *.pc класть в основной пакет, но в этом случае при  
> установке пакета %name будут вытягиваться по зависимости все *-devel, а  
> это может быть немалый довесок.

Для сборки как правило требуется не бинарь под /usr/lib/mono/gac/,
а специальный симлинк где-то приблизительно под /usr/lib/mono/%name.
Поэтому достаточно будет переместить этот каталог в *-devel пакет.

> >Ещё претензия по сборке mono: убрать всё зависимости, выставленные  
> >вручную.  Например, сейчас mono требует libicu.  Я так и не нашёл,  
> >где там зашита зависимость на libuci.  Это наверное просто наколка.
> 
> Нет. Раньше libicu использовался для i18n в Моно. Сейчас - не знаю,  
> надо проверить.

Вроде не используется, я грепал и так и сяк. :)

> >В общем, лучшее, что может сделать maintainer по части зависимостей  
> >-- это ПРОСТО запускать buildreq.  Всё остальное должно волшебным  
> >образом получиться автоматически, а если что-то не получается, значит  
> >надо фиксить сборочную среду/технологию сборки.  Таково мое понимание  
> >технологичности разработки пакетов.
> 
> Выглядит заманчиво, но я не поведусь ;) Уж я не знаю, что сделали для  
> этого за последние полгода - я просто был в оффлайне всё это время. Но:
> 1. не все используемые внешние библиотеки прописаны в *.dll.config  
> (были, и, поручусь, ещё есть)2. (Пока) Нет способа полностью  
> автоматизированно выловить директивы использования внешних библиотек в  
> коде. (Вам же не приходит в голову прочёсывать C-программу в поисках  
> dlopen()?)

А какие есть способы "прятать" использование внешних библиотек в коде?

В случае с ELF'ами мы и не вылавливаем dlopen, но мы можем выловить
DT_NEEDED (явные зависимости на разделяемые библиотеки).  Так и в случае
с mono, мы должны вылавливать явные зависимости из 'monodis --moduleref'.
Если кто-то "прячет" зависимости в dlopen или куда-то ещё, то он
лишается благ цивилизации.

С неполными или неправильными данными в *.dll.config самая сложная
проблема.  Чтобы это более-менее работало нужно сделать как минимум две
нетривиальные вещи:
1) Желательно в rpm-build реализовать новую модульную подсистему fixup,
по аналогии с requires и provides.  Типа чтобы можно было сделать скрипт
/usr/lib/rpm/mono.fixup и он автоматически исправлял *.dll.config файлы
в %buildroot.
2) Сейчас нет "системного" способа работы с XML файлами, даже для
чтения, а нужно делать inplace edit.  Вот нужно найти такой способ чтобы
было дёшево и сердито.  Я склоняюсь к какому-нибудь перловому модулю,
типа perl-XML-Simple, но это нужно пробовать.  Несколько неприятно,
что потянутся перловые модули, но если "системного" способа всё равно
нет, то придётся утилизировать какой-то несистемный.

Ну и
3) Нужно понять как сам mono работает когда в *.dll.config неполная
информация, т.е. как он выходит на "настоящую" библиотеку с сонеймом,
и мимикрировать эту логику в mono.fixup.

> В конце замечу, что, Алексей, Вы меня несказанно радуете участием в  
> нашей скорбной участи поддержки mono-пакетов ;-) Большое Вам спасибо!

На данном этапе я по минимуму передалал почти всё что хотел, при этом
сломалось минимальное число пакетов.  Думаю что теперь Mono Team следует
перепилить *-sharp пакеты как обсужадлось, чтобы работал buildreq.
Лучше это делать в топологическом порядке, т.е. начинать с "наиболее
базовых" пакетов и заканчивая теми, которые уже зависят от базовых.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]