[devel] Java autoreq/autoprov draft

[Damir Shayhutdinov]

> громко хлопаю в ладоши!
> Дамир, это изящно и правильно архитектурно!
Спасибо :) Хотя и у такой системы есть некоторые недостатки - например
если в пакете  файлы лежат в незапакованном виде в виде вороха .class
файлов - то для них нельзя создать Provides. :(

> я искренне рад за будущее Java в ALT.
> Осталось это всё оформить в виде /usr/lib/rpm/{prov,req}.java ,
> положить в rpm-build-java и повесить FR на пакет rpm-build (я и сам
> прошёл этот путь).
Ага, буду смотреть как сделано это для mono.

> Позволю себе один^Wпару комментариев:
> 1. готовые noarch пакеты, которые пользователь будет ставить, не будут
> предоставлять ничего.
Это не страшно. Сторонние пакеты имеют свою систему зависимостей,
заботливо внесенную вручную в теги Requires.

С другой стороны, проблема того, что эти пакеты не будут предоставлять
ничего, возникнет только в том случае, если пользователь захочет
какой-то пакет из репозитария ALT-а заменить на сторонний. В этом
случае ему также придется заменять на сторонние все пакеты, которые
зависят от этого заменяемого пакета. По-моему, такая ситуация является
нормальной - если используешь внешний репозиторий, резолвишь
зависимости внешними средствами (aka ССЗБ).

> 2. К сожалению, src.rpm/spec, взятые из внешних источников нужно будет
> слегка переделывать. Добавить сборочные зависимости на /proc и
> rpm-build-java (кстати, их по-любому нельзя заливать в инкоминг - нужно
> подписывать пакет)
Такие переделки в принципе может делать простейший скрипт. В идеале
вся эта куча .src.rpm прогоняется через этот скрипт, загоняется в
хэшер и на выходе получается пригодные к инкамингу пакеты. При должной
сноровке и безгеморройности этого процесса поддерживать такие пакеты в
Сизифе сможет даже робот.

> 3. То, что в Джаве нет, но есть в .Net (читай, в Mono) - версии этих
> самых библиотек. Соответственно в нашем RPM эти зависимости выглядят
> так:
> $ rpm -qR monodoc | grep mscorlib
> mono(mscorlib) = 1.0.5000.0
> А с Джавой получится как с библиотеками без soversion. Впрочем, это
> очевидно, если задуматься.

Версии прописаны в META-INF/MANIFEST.MF (тег Implemetation-Version)
Или можно ставить их по версии пакета, так меньше путаницы.

Так что с Provides проблем быть не должно. А вот с Requires...
Ставить жесткую зависимость на версию как-то странно - при обновлении
пакета придется пересобирать все что от него зависит. В принципе,
можно отдать это на откуп сборщику - если есть какие-то ограничения по
версиям, то пусть он вписывает их в Requires.

Например Requires: Java(ant) >= 1.7.0

>
> Удачи!
Спасибо за комментарии.