[devel] Java autoreq/autoprov draft

[Damir Shayhutdinov]

> Здесь выполняется (причем не совсем корректно) часть работы, которую rpm
> должен выполнять при установке пакетов: соединять названия пакетов по
> виртуальным зависимостям и решать, удовлетворены виртуальные зависимости
> или нет.  Т.е. зависимости на уровне jar -- это в таком случае
> получается что-то среднее между названиями пакетов и "настоящими"
> виртуальными зависимостями.
Угу.

> Когда нужный jar файл из /usr/share/java/* найден, тогда вместо
> виртуальной зависимости java($jar) можно ставить зависимость просто
> на /usr/share/java/$jar.jar или даже `rpm -qf /usr/share/java/$jar.jar'.
Так оно и предполагалось сделать.

> Т.е. виртуальные зависимости специального вида -- не самоцель;
> предполагается, что, по сравнению с именами пакетов, они более точно
> описывают внутреннюю структуру "настоящих" зависимостей.
Главным образом, они не дают программисту забыть нужную зависимость.
То есть они описывают необходимые зависимости, но не достаточные.

> > Впрочем, если забить на разбухание базы - то у меня на гит в
> > rpm-build-java лежит файл java.req, в котором в качестве
> > промежуточного результата используется список классов, который
> > использует пакет. Если этот список в текущем виде сконвертировать в
> > Java(имя класса) и представить как Requires - то получится все очень
> > хорошо. Только тогда еще надо рисовать скрипт java.prov, который будет
> > вытаскивать из .jar имена классов и предоставлять их как Provides.
>
> Если я правильно понимаю, что *.jar -- это просто архивы *.class файлов,
> причем "на самом деле" зависимости существуют именно между *.class
> файлами; то, по-моему, лучше делать зависимости на уровне class-файлов.
Угу, просто их количество исчисляется десятками и сотнями. Потянет rpm такое?
Если потянет - то я готов это сделать.