From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 15 Feb 2007 16:36:58 +0200 (EET) From: Igor Vlasenko To: ALT Devel discussion list In-Reply-To: <20070215110738.GM9824@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Received-SPF: pass (dad.imath.kiev.ua: domain of vlasenko@dad.imath.kiev.ua designates 127.0.0.1 as permitted sender) receiver=dad.imath.kiev.ua; client-ip=127.0.0.1; helo=localhost; envelope-from=vlasenko@dad.imath.kiev.ua; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; Cc: Damir Shayhutdinov Subject: Re: [devel] Java autoreq/autoprov draft X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 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: Thu, 15 Feb 2007 14:37:02 -0000 Archived-At: List-Archive: List-Post: On Thu, 15 Feb 2007, Alexey Tourbin wrote: > Откуда заключение, что если некий пакет требует /asdf/zxcv, то после > перегенерации хешей apt автоматически увидит Provides: /asdf/zxcv, > (если существует пакет с файлом /asdf/zxcv)? > > Как раз таки никакой Provides не появится, насколько я знаю, будет > unmet. Впрочем, идея интересная. Жаль, что apt так себя ведет :( В любом случае, думаю, стоит внедрять автоматизированные java-requires/provides уже после релиза. Считаю, что гораздо важнее сейчас добиться совместимости с JPackage, чтобы пользователь мог просто добавить в /etc/apt/sources.list rpm [JPackage] MIRROR VERSION/generic free rpm-src [JPackage] MIRROR VERSION/generic free non-free и мог свободно обновляться прямо с JPackage. Обоснование: -0------------------------------------------ Сейчас в ALT только 2 человека (я и Дамир) занимаются java, и 2-м человекам просто не под силу *качественно* поддерживать те же 150 альтовских пакетов (тем более те же 550 пакетов Jpackage). Я вижу разумный выход в достижении такого уровня совместимости с JPackage, когда разработчик мог бы сосредоточиться на небольшом числе ключевых пакетов, а остальные пакеты механически импортировались бы (например, скриптом) из JPackage, добавляя в спек любые Альтовские фенечки, которые захотим добавить. Так все (RH,Fedora,Mandriva,...) и делают. -0------------------------------------------ Примером служит хорошая сборка jpackage-utils от Дамира, там пакет причесан по-альтовски, (тот же macros.jpackage в /etc/rpm/macros.d/jpackage) но если кто-то захочет поставить пакет jpackage-utils из JPackage (например, поддержка новой JVM), то ничего в системе не сломается, те же макросы будут браться и из /etc/rpm/macros.jpackage. кстати, думаю, ей пора уже в Сизиф. {пересесение с rpm-build-java по %_javadir %_datadir/java %_javadocdir %_datadir/javadoc не есть конфликтом, пересечение со старым java-common по директориям тоже есть конфликтом. В перспективе завистмости на java-common и сам пакет java-common надо булет выбросить в obsolete, и использовать только jpackage-utils.} (Дамир: ?) Генерирование Provides: специального вида java(xalan-j) (в отличие от Requires:) такую совместимость сломают, почему я и предлагал генерировать зависимости на файлы вида Requires: /usr/share/java/xalan-j.jar Теперь предлагаю (из-за проблем с apt) пойти еще дальше и генерировать тогда уже зависимости на имя пакета: вида Requires: xalan-j (но только после релиза 3.1) :) при этом зависимость на интерфейс, а не на конкретный пакет придется наверно разруливать /etc/buildreqs/packages/substitute.d либо встроить в rpm-build-java аналогичный механизм. Кстати. В текущем подходе есть некоторые грабли с зависимостями, связанные с тем, что зависимости ищутся только в установленных пакетах. Надежннее было бы лезть чем-то вроде дизассемблера в собранные классы, и вытягивать зависимости прямо из них. Например, http://linux.softpedia.com/get/Programming/Disassemblers/jclassinfo-1156.shtml Пока пытаюсь понять, чем это можно сделать проще всего. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine