ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] rpm 4.0.4-alt82
@ 2007-12-03 12:50 Alexey Tourbin
  2008-01-14 19:00 ` Dmitry V. Levin
  0 siblings, 1 reply; 5+ messages in thread
From: Alexey Tourbin @ 2007-12-03 12:50 UTC (permalink / raw)
  To: devel

On Tue, Nov 27, 2007 at 06:31:18PM +0300, Alexey Tourbin wrote:
> В общем, у меня сейчас есть идея включить поиск всех симлинков
> на межпакетные зависимости.  Это защищает от неупаковки таргетов.
> Т.е. проверка типа [ -e "$RPM_BUILD_ROOT$f" ] это такая лавочка,
> что файл вроде бы должен "где-то" быть, но нет никакой гарантии,
> что его потом вообще куда-нибудь запакуют.  Эту лавочку желательно
> закрыть.  Будут появляться зависимости на файлы, и rpm сможет
> оптимизировать/удалить эти зависимости в пределах одного подпакета
> (речь идёт о подходе который реализован в 4.0.4-alt81-6-g6e73a89).
> С другой стороны, это как минимум означает, что у каждого lib*-devel
> пакета из-за симлнка /usr/lib/lib*.so -> /usr/lib/lib*.so.X.Y появится
> "файловая" зависимость на /usr/lib/lib*.so.X.Y.
> 
> То есть, с одной стороны, дополнительные зависимости между
> подпакетами защищают от ошибок упаковки.  С другой стороны, если всё
> упаковано правильно, то дополнительные виртуальные зависимости
> становятся излишними и их можно каким-то образом оптимизировать.
> Сейчас есть возможность начать делать первую часть (ставить
> дополнительные виртуальные зависимости), но пока нет хорошей идеи
> как делать вторую часть (удалять совпадающие виртуальные зависимости
> при жесткой связи между подпакетами).
> 
> С третьей стороны, полная оптимизация совпадающих зависимостей
> при жесткой связи между подпакетами -- для меня это ломка стереотипов.
> То есть если rpm перестанет явно зависеть от librpm-4.0.4.so (вследствие
> жесткой зависимости на librpm = %version-%release) то мне придётся
> к этому какое-то время привыкать.  То есть это очень сильная
> оптимизация, которая сейчас может противоречить привычной интуиции.

У меня предварительно готова новая сборка rpm 4.0.4-alt82.
Я пока воспринимаю ещё как экспериментальную.  Хотелось бы замутить
пересборку сизифа с 4.0.4-alt82 и потом проверить/обсудить, устраивает
ли нас новая схема зависимостей или нет.

    4.0.4-alt82
    
    - reqprov.c (addReqProv): implemented optimization of "self-requires"
      dependencies on packaged files
    - find-package, shell.req, pkgconfiglib.req, symlinks.req: do not
      completely ignore dependencies on files which are under RPM_BUILD_ROOT;
      that is, emit "file-level" dependencies which will be optimized out by
      addReqProv() within a single subpackage, but will protect from unpackaged
      files between subpackages; works best with apt-utils >= 0.5.15lorg2-alt17
    - lib.req: try to emit file-level dependencies instead of "soname-level"
      dependencies on private libraries (see git log for details); this can
      largely reduce the need for %%add_findprov_lib_path which is "public
      provides for private libraries"

Здесь два существенных изменения.  Во-первых, будут проставляться все
файловые зависимости на файлы которые обнаруживаются под RPM_BUILD_ROOT.
Раньше зависимости такого рода просто игнорировались -- считалось, что
maintainer должен запаковать всё что нужно и при этом правильно
расставить зависимости между подпакетами.  Теперь эта "лавочка"
прикрывается.

В пределах одного ПОДПАКЕТА все файловые зависимости будут
оптимизироваться (удаляться).  Но теперь появится много зависимостей
которые актуальны для связей между РАЗНЫМИ подпакетами (собранными из
одного исходного пакета).  Например, у librpm-devel (если собрать его
два раза) теперь зависимости изменятся так:

$ compare_packages -a -R -- ~sisyphus/files/i586/RPMS/librpm-devel-4.0.4-alt81.i586.rpm -- librpm-devel-4.0.4-alt82.athlon.rpm
--- /tmp/.private/at/compare_packages.IlbTPR4179/1      2007-12-03 15:32:59 +0300
+++ /tmp/.private/at/compare_packages.IlbTPR4179/2      2007-12-03 15:32:59 +0300
@@ -1,9 +1,13 @@
+/usr/lib/librpm-4.0.4.so  
+/usr/lib/librpmbuild-4.0.4.so  
+/usr/lib/librpmdb-4.0.4.so  
+/usr/lib/librpmio-4.0.4.so  
 bzlib-devel  
 libbeecrypt-devel  
 libdb4.4-devel  
 libpopt-devel  
-librpm = 4.0.4-alt81
-librpmbuild = 4.0.4-alt81
+librpm = 4.0.4-alt82
+librpmbuild = 4.0.4-alt82
 rpmlib(CompressedFileNames) <= 3.0.4-1
 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
 rpmlib(VersionedDependencies) <= 3.0.3-1
$

Добавившиеся зависимости означают что пакет librpm-devel "не может жить"
без файлов /usr/lib/librpm-4.0.4.so и т.д. (потому что там есть симлинки
для линковки которые показывают на эти файлы).  Но этих файлов нет в
самом пакете librpm-devel, поэтому кто-то их должен "предоставлять" (на
самом деле явного provides не требуется, apt будет хорошо разрешать
файловые зависимости начиная с alt17).  На практике эти файлы должен
содержать какой-то другой подпакет, собранный из этого же исходного
пакета (хотя сейчас нет способа передать при помощи зависимости именно
этот строгий смысл).

То есть, с одной стороны, как я уже писал, появляется много "лишних" на
первый взгляд зависимостей.  С другой стороны, эта зависимости защищают
от ошибок неупаковки файлов между подпакетами.

Далее можно будет реализовать оптимизацию виртуальных зависимостей при
жесткой связи между подпакетами (= %version-%release).  Но это не очень
хорошо вписывается в архитектуру rpm, и, кроме того, слишком сильная
"очистка" виртуальных зависимостей между подпакетами может противоречить
интуиции maintainer'а.

Второе изменение на практике сводится к тому, что в openoffice.org
теперь можно будет отключить %add_findprov_lib_path, чтобы он не
предоставлял несколько сотен "приватных" виртуальных библиотек.
При этом зависимости между подпакетами openoffice.org-kde и -gnome
будут сведены к зависимостям на файлы, то есть вместо зависимостей типа

$ rpm -qpR openoffice.org-kde-2.3.0-alt6.i586.rpm |grep /usr/lib
...
/usr/lib/OpenOffice.org2/program/libcomphelp4gcc3.so
...
/usr/lib/OpenOffice.org2/program/libpsp680li.so(LIBPSPRINT_1_0)
...
$

будут "чисто файловые" зависимости
/usr/lib/OpenOffice.org2/program/libcomphelp4gcc3.so
/usr/lib/OpenOffice.org2/program/libpsp680li.so

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

Идея тут в том, что "сонеймы со скобками" нужно явно предоставлять
через provides (что в случае с openoffice.org заметно засоряет базу
зависимостей), а "файлы" явно предоставлять не нужно, apt их "оживляет"
по мере необходимости.

PS: у меня истёк gpg-ключ 0x38E7BB46. Ж(


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-01-14 23:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-03 12:50 [devel] rpm 4.0.4-alt82 Alexey Tourbin
2008-01-14 19:00 ` Dmitry V. Levin
2008-01-14 19:56   ` Alexey Tourbin
2008-01-14 20:26     ` Dmitry V. Levin
2008-01-14 23:19       ` Alexey Tourbin

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