From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 1 Mar 2004 20:01:37 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: devel@altlinux.ru, sisyphus@altlinux.ru Subject: Re: [devel] =?koi8-r?B?7dXTz9Ig1w==?= quis Message-ID: <20040301170137.GH10460@localhost.localdomain> Mail-Followup-To: =?koi8-r?B?5MXOydMg883J0s7P1w==?= , devel@altlinux.ru, sisyphus@altlinux.ru References: <20040229221333.GC5036@localhost.localdomain> <20040301042520.GF1875@solemn.turbinal.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Md/poaVZ8hnGTzuv" Content-Disposition: inline In-Reply-To: <20040301042520.GF1875@solemn.turbinal.org> Cc: 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: Mon, 01 Mar 2004 17:03:19 -0000 Archived-At: List-Archive: List-Post: --Md/poaVZ8hnGTzuv Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Mar 01, 2004 at 07:25:20AM +0300, Алексей Турбин wrote: >> 1. Убиение дупов. Периодически в разных пакетах я вижу полосы из нескольких >> /bin/sh, иногда и другие пакеты также дупятся. Это хоть и некритично, но AT> AFAIK, дупы уже убиваются, в пределах каждой стадии зависимостей. AT> Насчет /bin/sh вообще согласен: самые частые зависимости обычно самые AT> бесполезные (я даже убиваю некоторые бесполезные зависимости в AT> /usr/lib/rpm/perl.req). Система, в которой нет /bin/sh, просто AT> непригодна для какого-либо обновления. Зависимость на /bin/sh нужна AT> в архи-частных случаях. :) По крайней мере зависимость на функцию шелл-скрипта должна быть достаточным поводом, чтобы убрать зависимость на /bin/sh. А насчёт дупов... В аттаче пример списка requires из одного пакета. >> 2. Если требется, например libc.so.6 и libc.so.6(GLIBC_2.0), то первая запись AT> Прикрутите ispell к редактору. man что? (редактор -- vim). >> явно не имеет смысла ни для apt, ни для rpm (любой пакет которой provides >> второй вариант обязательно будет provides первый вариант, насколько я понимаю). >> Решение: для каждой зависимости вида lib([a-z]+).so.(\d+)\(.*\) удалять >> зависимость вида lib$1.so.$2 AT> Тогда будет невозможен анализ зависимостей типа AT> apt-get showpkg lib$1.so.$2 AT> т.е. "общий знаменатель" имеет смысл. Мда. Без более глубокого копания в apt сделать красиво не получится (хорошо бы научить apt обрабатывать "виртуальные" зависимости, которые физически не прописаны, но подразумеваются). А пока действительно в этом смысле ваш вариант оказывается лучше. >> 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) >> Красиво? Логика мне подсказывает, что лишь последняя запись здесь имеет смысл. AT> Тогда первая и последняя. Но произвольный формат symbol versioning AT> может не совпадать с rpmvercmp, а не хотелось бы внедрять неточные AT> алгоритмы. Для начала можно обработать конкретный частный случай. >> 5. libXXX и libXXX.so.Y >> Логика мне подсказывает, что вторая зависимость такого вида чаще всего >> является лишь уточнением первой. AT> Логика также подсказывает, что первая зависимость появилась вручную, а AT> вторая -- автоматически. Из чего вывод: не надо проставлять зависимости AT> вручную, кроме особых случаев. Претензии не ко мне :) >> 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 AT> У меня были мысли не эту тему, см. AT> Sun, 16 Nov 2003 [devel] packagereq/buildreq proposal AT> 20031116145830.GC1863@julia.office.altlinux.ru Можно ссылочку, или копию? >> Вопрос -- оно нам надо? В смысле -- я могу это сделать, но это имеет смысл AT> Думаю, что надо, но не всё сразу. :) AT> В целом, нужно стремиться к точным алгоритмам, а это сложнее, чем хаки. Разумеется. С другой стороны можно идти последовательным улучшением (добавляя хаки, логика которых прозрачна и работоспособность гарантирована). -- С уважением, Денис http://dimline.ru/ --Md/poaVZ8hnGTzuv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQ2xx9yLOUeHSdCYRAscbAJ9PRlc/2spDv+bpRVhtmFoYvlNEqgCaA0C1 nFLs32u1+K/apveMW0VkCcM= =nFH5 -----END PGP SIGNATURE----- --Md/poaVZ8hnGTzuv--