From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 1 Mar 2004 01:13:33 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: devel@altlinux.ru Message-ID: <20040229221333.GC5036@localhost.localdomain> Mail-Followup-To: =?koi8-r?B?5MXOydMg883J0s7P1w==?= , devel@altlinux.ru, sisyphus@altlinux.ru Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline Cc: sisyphus@altlinux.ru Subject: [devel] =?koi8-r?b?7dXTz9Ig1w==?= Requires X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 22:15:16 -0000 Archived-At: List-Archive: List-Post: --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Поглядел я тут в requires пакетов, и подумалсь мне -- их же можно в 2-3 раза короче сделать! У меня родилось несколько предложений по очистке requires. 1. Убиение дупов. Периодически в разных пакетах я вижу полосы из нескольких /bin/sh, иногда и другие пакеты также дупятся. Это хоть и некритично, но "неаккуратненько" (c) известный анекдот Предложение -- в findreq перед тем, как отдавать список найденых requires его отсортировать и почистить (sort|uniq) 2. Если требется, например libc.so.6 и libc.so.6(GLIBC_2.0), то первая запись явно не имеет смысла ни для apt, ни для rpm (любой пакет которой provides второй вариант обязательно будет provides первый вариант, насколько я понимаю). Решение: для каждой зависимости вида lib([a-z]+).so.(\d+)\(.*\) удалять зависимость вида lib$1.so.$2 3. Привожу пример: - libc.so.6 - libc.so.6(GLIBC_2.0) - libc.so.6(GLIBC_2.1) - libc.so.6(GLIBC_2.1.2) - libc.so.6(GLIBC_2.1.3) - libc.so.6(GLIBC_2.2) Красиво? Логика мне подсказывает, что лишь последняя запись здесь имеет смысл. Точно такая же извращённая ситуация со многими другими библиотеками (сходу вспоминаю libdl, libm, libacl). 4. Разборки с glibc-core. Существуют такие полезные библиотеки как libm.so и libdl.so. Зависимости на них встречаются часто, однако находятся они в glibc-core. Так как у меня есть большие сомнения, что когда-либо эти библиотеки (вернее их glibc-версии) будут отделены от glibc-core, то я предлагаю сделать так: Если есть, зависимость на libc.so.6(GLIBC_2.2), то зависимости на: libm.so.6 libdl.so.6 libm.so.6(GLIBC_2.1) (или любую другую версию _не больше_ чем требует libc) libdl.so.6(GLIBC_2.1) (или любую другую версию _не больше_ чем требует libc) 5. libXXX и libXXX.so.Y Логика мне подсказывает, что вторая зависимость такого вида чаще всего является лишь уточнением первой. Предложение: в подобных ситуациях удалять первую зависимость. 6. Есть пары пакетов, один из которых всегда требует другого. Обычно это какая-то программа, и основная библиотека, на которой она построена. Кроме того есть пакеты, всегда представляющие пару provides (например sh, который предоставляет sh и /bin/sh). Примеры: - tcl и libtcl - tk и libtk - acl и libacl - sh и /bin/sh Предложение: добавить механизм замен пар (или групп) пакетов на один, например: tcl + libtcl -> tcl tk + libtk -> tk acl + libacl -> acl sh + /bin/sh -> sh Реализация каждой их этих оптимизаций достаточно простая (всё вместе займёт пару часов, не считая тестирования), и я пока не вижу ни одного негативного побочного эффекта от этой фичи. Зато есть два основных позитивных, это уменьшение размера apt и rpm баз, увеличения скорости работы apt, увеличение скорости работы hasher'а. Вопрос -- оно нам надо? В смысле -- я могу это сделать, но это имеет смысл только при включении результата в Сизиф (и пользу от него мы получим только после ближайшей полной пересборки Сизифа). -- С уважением, Денис http://freesource.info --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQmQN9yLOUeHSdCYRApQJAKDGovW+jWCop9Br3STdWoMe0kaJqwCdHCrW vhmOdtwBrQF27DxhiPvQkVA= =g9F7 -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu--