[devel] Java autoreq/autoprov draft

[Igor Vlasenko]

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