From: Alexey Tourbin <at@altlinux.ru> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: [devel] private provides (was: rpm-build-mono find provides) Date: Tue, 27 Nov 2007 20:31:09 +0300 Message-ID: <20071127173109.GJ361@solemn.turbinal> (raw) In-Reply-To: <b966c1e40711270850l381b9554s919ff200c05607d@mail.gmail.com> [-- 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 --]
next prev parent reply other threads:[~2007-11-27 17:31 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-11-26 15:27 [devel] rpm-build-mono find provides Alexey Shabalin 2007-11-27 5:48 ` Ildar Mulyukov 2007-11-27 6:25 ` Alexey Tourbin 2007-11-27 9:12 ` Alexey Shabalin 2007-11-27 9:49 ` [devel] private provides Alexey Tourbin 2007-11-27 11:44 ` Alexey Tourbin 2007-11-27 9:52 ` [devel] rpm-build-mono find provides Alexey Tourbin 2007-11-27 16:50 ` Alexey Shabalin 2007-11-27 17:31 ` Alexey Tourbin [this message] 2007-11-27 17:47 ` [devel] private provides (was: rpm-build-mono find provides) Alexey Shabalin 2007-11-27 17:50 ` [devel] rpm-build-mono find provides Andrey Rahmatullin 2007-11-28 4:22 ` Ildar Mulyukov 2007-11-28 10:56 ` Alexey Shabalin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20071127173109.GJ361@solemn.turbinal \ --to=at@altlinux.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git