[devel] private provides (was: rpm-build-mono find provides)

[Alexey Tourbin <at@altlinux.ru>]

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

On Tue, Nov 27, 2007 at 07:50:21PM +0300, Alexey Shabalin wrote:
> > > > Докладываю, что provides для моно теперь не ищутся.
> > > > Точнее, ищутся только в MONO_LIBDIR=/usr/lib/mono и не проверяются в
> > > > других местах.
> > > > Указание в спеке (для beagle)
> > > > %add_findprov_lib_path %_libdir/beagle
> > > > никак не влияет.
> > > > проверил на f-spot - такая же ситуация.
> > > > Алексей расчитывать на вашу помощь?
> > >
> > > Это было сделано специально по результатам обсуждения около недели-двух
> > > назад.
> >
> > Так в beagle не должно появиться requires (в пределах главного
> > подпакета), которые "внутренне" предоставляются.  То есть внутренние
> > библиотеки за пределами /usr/lib/mono -- это личное дело пакета, они
> > и не должны предоставляться, а зависимости requires на такие библиотеки
> > должны взаимно уничтожаться.
> 
> Кстати это хорошо, что mono-программы не провайдят ничего за пределами
> /usr/lib/mono.

Точнее, за пределами /usr/lib/mono/gac/, с одним небольшим исключением
для mscorlib.dll.  Конечно хорошо.  Идея в том, что явно предоставлять
("для репозитария") нужно только то, что можно найти "стандартным
способом" (в частности, в стандартных путях для поиска этого дела).
Чего нельзя подцепить стандартным способом, того и не надо явно
предоставлять, чтобы не "сбивать" зависимости, то есть чтобы никто
не надеялся стандартно подцепить то, чего стандартно подцепить нельзя.

Правда, тут встаёт вопрос, как взаимно уничтожить "приватные" provides
и соответствующие им requires в пределах одного пакета, особено если
этот пакет распилен на несколько подпакетов.  В принципе такой способ
есть.  Надо над ним ещё подумать.

Эта проблема не специфична для mono.  Есть общая идея "узких"
межпакетных зависимостей, которые желательно разрешать без "глобального"
provides в репозатарии.  Я считаю, что в большинстве разумных случаев
эту проблему можно разрешить на уровне файловых зависимостей.  То есть
вместо зависимости типа mono(что-то) можно писать зависимость вида
/usr/lib/mono/foo/что-то.dll.  Тогда файловая зависимость будет
разрешаться существенно более автоматически, чем это могло бы быть
в случае с виртуальной зависимостью.

> Сейчас собираю новый monodevelop - теперь он  с собой несёт
> компоненты, которые уже есть в mono-* (например для баз данных).
> Причём раньше такого не было.
> Я понимаю, что это лучше оторвать от него, упаковать в сизиф нужные
> mono-addins и mono-mysql(bytefx-data-mysql всё-равно в апстриме не
> поддерживается), но боюсь времени/возможности в ближайшее время не
> будет.
> 
> А вообще оно кому-нибудь надо? кто возьмётся протестировать?

Это глупый вопрос.  Надо оно кому-нибудь или нет, это никто не скажет
даже за двадцать долларов.  Кому это сейчас нужно или не нужно это не
имеет никакого значения.  Вам сейчас нужно сделать систему фактически
для себя, чтобы она Вам нравилась.  Я в этом смысле как бы немного
неприлично помогаю делать систему, которая отчасти нравится в том числе
и мне самому.  Но наши вкусы могут не совпадать (хотя я и стараюсь не
делать глупостей).  Так что смотрите.

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