[devel] Java autoreq/autoprov draft

[Damir Shayhutdinov]

> В любом случае, думаю, стоит внедрять автоматизированные
> java-requires/provides уже после релиза.
Угу, двум человекам нереально.

> кстати, думаю, ей пора уже в Сизиф.
> {пересесение с 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)
Лучше по классам сделать.

> Кстати. В текущем подходе есть некоторые грабли с зависимостями,
> связанные с тем, что зависимости ищутся только в установленных
> пакетах.
> Надежннее было бы лезть чем-то вроде дизассемблера
> в собранные классы, и вытягивать зависимости прямо из них.
Это уже сделано - см. java.req из rpm-build-java у меня в гите.
Это как раз не проблема - по спецификации имена классов предшествуются
символом L и заканчиваются точкой с запятой - так что простой egrep -o
может без дизассемблера вытащить все зависимости.


> Например,
> http://linux.softpedia.com/get/Programming/Disassemblers/jclassinfo-1156.shtml
> Пока пытаюсь понять, чем это можно сделать проще всего.
Уже сделано, и максимально простым способом.