[devel] Java autoreq/autoprov draft

[devel] Java autoreq/autoprov draft

[Damir Shayhutdinov]

> А разве нельзя залезать в .jar, разбирать .class файлы и находить все
> объекты, которые в них используются? Так получится Requires.
> А Provides вообще получаются анализом содержимого .jar файла.
>
> Примеры зависимости: Java(org.apache.xpath.XPath)
> Правда получится довольно много этих самых Provides и Requires :( Зато
> автоматом.
Появилась идея получше. Так как минимальной файловой единицей в Java
является .jar-файл, то Provides/Requires можно в принципе
организовывать на них.

Вот например в пакете jakarta-oro

rpm -ql jakarta-oro | fgrep .jar
/usr/share/java/jakarta-oro.jar

находится один .jar файл.

Поэтому можно присвоить пакету jakarta-oro следующие auto provides:

Java(jakarta-oro)

Это выглядит довольно легко.

Теперь сложная часть - поиск Requires.

Для этого надо сначала пройтись по всем .jar файлам в /usr/share/java
и составить списки всех .class файлов находящихся в них.

for i in /usr/share/java/*.jar; do jar -tf $i | fgrep .class | cut -f
1 -d . > `basename $i .jar`; done

Получится список классов, которые содержатся в .jar-файле.

Теперь надо найти какие же из .jar-файлов, установленных в
/usr/share/java реально используются пакетом (auto requires).

Для проверки я взял пакет jakarta-oro-demo.

В нем скомпилированные классы находятся в незапакованном виде.
ls -1 /usr/share/java
ant
bcel.jar
excalibur-logkit.jar
geronimo-specs
jakarta-commons-collections.jar
jakarta-oro.jar
jakarta-regexp.jar
jakarta-servletapi4.jar
jaxp_parser_impl.jar
jaxp_transform_impl.jar
jdom.jar
jspapi5.jar
log4j.jar
serializer.jar
servletapi5.jar
servletapi.jar
velocity.jar
werken-xpath.jar
xalan-j.jar
xerces-j.jar
xml-commons-apis.jar
xml-commons-external.jar

После выполнения предыдущего скрипта у меня в текущей директории
получились вот такие вот файлы списков классов в каждом .jar

ls -1 .
bcel
excalibur-logkit
jakarta-commons-collections
jakarta-oro
jakarta-regexp
jakarta-servletapi4
jaxp_parser_impl
jaxp_transform_impl
jdom
jspapi5
log4j
serializer
servletapi
servletapi5
velocity
werken-xpath
xalan-j
xerces-j
xml-commons-apis
xml-commons-external

Я создал вот такой вот маленький скрипт-обертку для поиска requires:

cat ~/bin/find-java-requires
#!/bin/sh

JARLISTDIR=~/tmp/java #FIXME директория где лежат списки
for jarlist in $JARLISTDIR/*
do
        fgrep -qf "$jarlist" -- "$@" && echo "Java(`basename $jarlist`)"
done

Натравив его на .classes файлы из jakarta-oro-demo командой

find /usr/share/doc/jakarta-oro-2.0.8/ -name '*.class' -print0 | xargs
-r0 find-java-requires
я получил вывод
Java(jakarta-oro)

Вот какие автозависимости можно поставить пакету jakarta-oro-demo.

Теперь про пакеты с .jar файлами.

Возьмем например пакет velocity.

rpm -ql velocity | fgrep .jar
/usr/share/java/velocity.jar

Идея такая - распаковываем этот .jar файл в какую-нибудь временную
директорию, получаем список .class файлов и натравливаем на них
find-java-requires.

cat ~/bin/find-java-jar-requires
#!/bin/sh
OURDIR=`mktemp -dt`
cd "$OURDIR" && jar -xf "$1"
find "$OURDIR" -name '*.class' -print0 | xargs -r0 find-java-requires
rm -rf -- "$OURDIR"

Теперь смотрим результаты:
find-java-jar-requires /usr/share/java/velocity.jar
Java(excalibur-logkit)
Java(jakarta-commons-collections)
Java(jakarta-oro)
Java(jakarta-servletapi4)
Java(jdom)
Java(log4j)
Java(servletapi)
Java(servletapi5)
Java(velocity)
Java(werken-xpath)
Java(xml-commons-apis)
Java(xml-commons-external)
Вуаля!

Можно посмотреть еще остальные .jar файлы - например

find-java-jar-requires /usr/share/java/log4j.jar
Java(log4j)
Java(xml-commons-apis)
Java(xml-commons-external)

find-java-jar-requires /usr/share/java/bcel.jar
Java(bcel)
Java(jakarta-regexp)

find-java-jar-requires /usr/share/java/jakarta-servletapi4.jar
Java(jakarta-servletapi4)
Java(jspapi5)
Java(servletapi)
Java(servletapi5)

На первый взгляд все работает :)

Жду критики, комментариев и предложений по улучшению.

Re: [devel] Java autoreq/autoprov draft

[Ildar Mulyukov]

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

Позволю себе один^Wпару комментариев:
1. готовые noarch пакеты, которые пользователь будет ставить, не будут  
предоставлять ничего.
2. К сожалению, src.rpm/spec, взятые из внешних источников нужно будет  
слегка переделывать. Добавить сборочные зависимости на /proc и  
rpm-build-java (кстати, их по-любому нельзя заливать в инкоминг - нужно  
подписывать пакет)
3. То, что в Джаве нет, но есть в .Net (читай, в Mono) - версии этих  
самых библиотек. Соответственно в нашем RPM эти зависимости выглядят  
так:
$ rpm -qR monodoc | grep mscorlib
mono(mscorlib) = 1.0.5000.0
А с Джавой получится как с библиотеками без soversion. Впрочем, это  
очевидно, если задуматься.

Удачи!

On 07.02.2007 04:21:37, Damir Shayhutdinov wrote:
> На первый взгляд все работает :)
> 
> Жду критики, комментариев и предложений по улучшению.

-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [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

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

Re: [devel] Java autoreq/autoprov draft

[Ildar Mulyukov]

On 07.02.2007 14:23:13, Damir Shayhutdinov wrote:
>>  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
Да, это пока придётся делать руками. В mono уже пошли дальше -  
придумали так называемые "policy"-сборки, которые декларируют  
совместимость.. Тут, видимо, Джаве ещё долго догонять... В общем, если  
нужны идеи в эту сторону - гуглите "mono policy" и т.п.

Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Java autoreq/autoprov draft

[Igor Vlasenko]

On Wed, Feb 07, 2007 at 11:23:13AM +0300, Damir Shayhutdinov wrote:
> > громко хлопаю в ладоши!
> > Дамир, это изящно и правильно архитектурно!
> Спасибо :) Хотя и у такой системы есть некоторые недостатки - например
> если в пакете  файлы лежат в незапакованном виде в виде вороха .class
> файлов - то для них нельзя создать Provides. :(
Присоединяюсь :)

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

И я свои 5 коп. На носу релиз, и эти и все сопутствующие 
изменения надо будет сделать в виде транзакции. т. е. либо 
вливать в Сизиф уже готовый пересобирающийся набор всех 
java пакетов, либо оставить как есть. 
Хуже всего --- разломанный Сизиф в якобы фризе.
Поэтому предлагаю пока ложить не в Сизиф
(git/dedal).

> Такие переделки в принципе может делать простейший скрипт. В идеале
> вся эта куча .src.rpm прогоняется через этот скрипт, загоняется в
> хэшер и на выходе получается пригодные к инкамингу пакеты. При должной
> сноровке и безгеморройности этого процесса поддерживать такие пакеты в
> Сизифе сможет даже робот.
Из jpackage :)

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java autoreq/autoprov draft

[Igor Vlasenko]

On Wed, Feb 07, 2007 at 11:23:13AM +0300, Damir Shayhutdinov wrote:
> С другой стороны, проблема того, что эти пакеты не будут предоставлять
> ничего, возникнет только в том случае, если пользователь захочет
> какой-то пакет из репозитария ALT-а заменить на сторонний. В этом
> случае ему также придется заменять на сторонние все пакеты, которые
> зависят от этого заменяемого пакета. По-моему, такая ситуация является
> нормальной - если используешь внешний репозиторий, резолвишь
> зависимости внешними средствами (aka ССЗБ).

Я вчера об этом думал.

Поскольку обеспечить _качественную_ поддержку тех же 500 пакетов из 
jpackage без поддержки jpackage
вручную не реально, такая идеология чревата.

По счастью есть элегантный выход:
Генерировать Requires не вида Java(castor), а вида
/usr/share/java/castor.jar

Тогда генерировать Provides: не нужно, jpackage policy 
требует обязательного наличия такого симлинка в rpm пакете.

Это уже не будет ломать совместимость с jpackage.

Считаю очень важной возможность установить rpm прямо с jpackage.org.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java autoreq/autoprov draft

[Damir Shayhutdinov]

> Поскольку обеспечить _качественную_ поддержку тех же 500 пакетов из
> jpackage без поддержки jpackage
> вручную не реально, такая идеология чревата.
>
> По счастью есть элегантный выход:
> Генерировать Requires не вида Java(castor), а вида
> /usr/share/java/castor.jar
>
> Тогда генерировать Provides: не нужно, jpackage policy
> требует обязательного наличия такого симлинка в rpm пакете.
Симлинк то есть. В Provides он у пакетов с jpackage появится? Не
появится. Как апт узнает, какой пакет предоставляет зависимость
/usr/share/java/castor.jar?

> Это уже не будет ломать совместимость с jpackage.
>
> Считаю очень важной возможность установить rpm прямо с jpackage.org.

Я вчера собрал jpackage-utils для Сизифа. Пока напрямую установить
пакеты с jpackage.org не удается - надо еще адаптировать к нашим
java-пакетам.

Например он требует java-devel, а у нас оно называется j2se-devel. И т.д.

Re: [devel] Java autoreq/autoprov draft

[Igor Vlasenko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1055 bytes --]

On Thu, 8 Feb 2007, Damir Shayhutdinov wrote:
>> По счастью есть элегантный выход:
>> Генерировать Requires не вида Java(castor), а вида
>> /usr/share/java/castor.jar
>> Тогда генерировать Provides: не нужно, jpackage policy
>> требует обязательного наличия такого симлинка в rpm пакете.
>Симлинк то есть. В Provides он у пакетов с jpackage появится? Не
>появится. 

Появится, Появится :) 
Все файлы, папки, симлинки пакета автоматически входят в 
его Provides:, вручную их не нужно выписывать.

я Вам даже примеры сваял (см. attachment) ---
jprobe1 содержит симлинк, а jprobe2 явно хочет (Requires)
этот симлинк.
Соберите, установите, и поверите.

> Я вчера собрал jpackage-utils для Сизифа. Пока напрямую установить
> пакеты с jpackage.org не удается - надо еще адаптировать к нашим
> java-пакетам.
> Например он требует java-devel, 
> а у нас оно называется j2se-devel. И т.д.

Угу :( у меня есть аналоги из jpackage, 
как раз хочу сравнить и поправить.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


[-- Attachment #2: Type: TEXT/PLAIN, Size: 538 bytes --]

Name:		jprobe1
Version:	0.01
Release:	1%{?dist}
Summary:	probe

Group:		Java
License:	free
#URL:		
BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch: noarch

%description
config scripts

%prep

%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/etc/some_dir
touch $RPM_BUILD_ROOT/etc/some_dir/some_file
ln -s some_file $RPM_BUILD_ROOT/etc/some_dir/some_link

%clean
rm -rf $RPM_BUILD_ROOT

%post

%files
%defattr(-,root,root,-)
/etc/some_dir

%changelog

[-- Attachment #3: Type: TEXT/PLAIN, Size: 521 bytes --]

Name:		jprobe2
Version:	0.01
Release:	1
Summary:	probe

Group:		Java
License:	free
#URL:		
BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch: noarch
Requires: /etc/some_dir/some_link

%description
config scripts

%prep

%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/etc/some_dir
touch $RPM_BUILD_ROOT/etc/some_dir/some_file2

%clean
rm -rf $RPM_BUILD_ROOT

%post

%files
%defattr(-,root,root,-)
/etc/some_dir/some_file2

%changelog

Re: [devel] Java autoreq/autoprov draft

[Damir Shayhutdinov]

08.02.07, Igor Vlasenko<vlasenko.imath.kiev.ua> написал(а):
> On Thu, 8 Feb 2007, Damir Shayhutdinov wrote:
> >> По счастью есть элегантный выход:
> >> Генерировать Requires не вида Java(castor), а вида
> >> /usr/share/java/castor.jar
> >> Тогда генерировать Provides: не нужно, jpackage policy
> >> требует обязательного наличия такого симлинка в rpm пакете.
> >Симлинк то есть. В Provides он у пакетов с jpackage появится? Не
> >появится.
>
> Появится, Появится :)
> Все файлы, папки, симлинки пакета автоматически входят в
> его Provides:, вручную их не нужно выписывать.
Странно это у нас как-то работает
Я вот попробовал сделать так:

sudo apt-get install /usr/share/java/ant/ant.jar
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
E: Невозможно найти пакет
И получил фигу.

> я Вам даже примеры сваял (см. attachment) ---
> jprobe1 содержит симлинк, а jprobe2 явно хочет (Requires)
> этот симлинк.
> Соберите, установите, и поверите.
На ALT-е они даже не собираются. Но после запатчивания таки сработало
- jprobe2 затребовал при установке jprobe1.
Похоже тут так - если какой-то файл никто в репозитории не требует -
тогда apt не считает его Provides-ом и не хочет устанавливать по
apt-get install.
А как кто-то этот файл потребует - так сразу тутже и появляется и
Provides, и Requires.

Ну значит зависимости на /usr/share/java/*.jar будут работать. И то хорошо. :)

> > Я вчера собрал jpackage-utils для Сизифа. Пока напрямую установить
> > пакеты с jpackage.org не удается - надо еще адаптировать к нашим
> > java-пакетам.
> > Например он требует java-devel,
> > а у нас оно называется j2se-devel. И т.д.
>
> Угу :( у меня есть аналоги из jpackage,
> как раз хочу сравнить и поправить.
Да это можно одним-двумя compat-пакетами исправить, собирающимися из
того же src.rpm что и jpakage-utils.

Например пакет jpackage-devel будет Requires: j2se-devel и Provides:
java-devel. Все равно эта java-devel нужна только для jpackage.

Re: [devel] Java autoreq/autoprov draft

[Igor Vlasenko]

On Thu, Feb 08, 2007 at 03:17:14PM +0300, Damir Shayhutdinov wrote:
> > >> Генерировать Requires не вида Java(castor), а вида
> > >> /usr/share/java/castor.jar
> > >> Тогда генерировать Provides: не нужно, jpackage policy
> > >> требует обязательного наличия такого симлинка в rpm пакете.
> > я Вам даже примеры сваял (см. attachment) ---
> > jprobe1 содержит симлинк, а jprobe2 явно хочет (Requires)
> > этот симлинк.
> На ALT-е они даже не собираются. Но после запатчивания таки сработало

АЛЬТа под рукой не оказалось :)

> Ну значит зависимости на /usr/share/java/*.jar будут работать. И то хорошо. :)

:)

> > Угу :( у меня есть аналоги из jpackage,
> > как раз хочу сравнить и поправить.
> Да это можно одним-двумя compat-пакетами исправить, собирающимися из
> того же src.rpm что и jpakage-utils.

Там просил Eugene Prokopiev пофиксить 
https://bugzilla.altlinux.org/show_bug.cgi?id=9766,
так что все одно придется править все j2se-* пакеты.
:(
заодно обновлю, причешу.

Вопрос к народу;
Кстати. Вот тут я обновляю пакеты j2se-*, а лицензия там туманна.
Мы их пакуем, а та же fc- нет. Почему они пакуются у нас?
Кто помнит?

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

On Thu, Feb 08, 2007 at 02:56:20PM +0200, Igor Vlasenko wrote:
> Вопрос к народу;
> Кстати. Вот тут я обновляю пакеты j2se-*, а лицензия там туманна.
> Мы их пакуем, а та же fc- нет. Почему они пакуются у нас?
> Кто помнит?

Кстати.  Sun вроде бы выпустил Java, или, во всяком случае, существенную
ее часть, под GPLv2.  Кто-нибудь смотрел, как это собрать для сизифа,
или я что-то пропустил?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Thu, Feb 08, 2007 at 03:17:14PM +0300, Damir Shayhutdinov wrote:
> На ALT-е они даже не собираются. Но после запатчивания таки сработало
> - jprobe2 затребовал при установке jprobe1.
> Похоже тут так - если какой-то файл никто в репозитории не требует -
> тогда apt не считает его Provides-ом и не хочет устанавливать по
> apt-get install.
> А как кто-то этот файл потребует - так сразу тутже и появляется и
> Provides, и Requires.

Откуда заключение, что если некий пакет требует /asdf/zxcv, то после
перегенерации хешей apt автоматически увидит Provides: /asdf/zxcv,
(если существует пакет с файлом /asdf/zxcv)?

Как раз таки никакой Provides не появится, насколько я знаю, будет
unmet.  Впрочем, идея интересная.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [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

Re: [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
> Пока пытаюсь понять, чем это можно сделать проще всего.
Уже сделано, и максимально простым способом.

Re: [devel] Java autoreq/autoprov draft

[Igor Vlasenko]

On Thu, 15 Feb 2007, Damir Shayhutdinov wrote:
>> по директориям тоже есть конфликтом.
> Фразы про конфликты не понял. Пропущены некоторые слова?
опУчатка. хотел сказать
по директориям тоже не есть конфликтом.

>> Пока пытаюсь понять, чем это можно сделать проще всего.
>Уже сделано, и максимально простым способом.
Там я пример некоторой конкретной ситуации себе мыслил.
Я тогда позже напишу, что хотел сказать, 
это требует времени, а уже пора бежать.
:(



_______________________________________________
Devel mailing list
Devel@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4194 bytes --]

On Thu, Feb 15, 2007 at 04:36:58PM +0200, Igor Vlasenko wrote:
> On Thu, 15 Feb 2007, Alexey Tourbin wrote:
> > Откуда заключение, что если некий пакет требует /asdf/zxcv, то после
> > перегенерации хешей apt автоматически увидит Provides: /asdf/zxcv,
> > (если существует пакет с файлом /asdf/zxcv)?
> > 
> > Как раз таки никакой Provides не появится, насколько я знаю, будет
> > unmet.  Впрочем, идея интересная.
> 
> Жаль, что apt так себя ведет :(

Не apt так себя ведет, а хеши так сгенерированы.  Т.е., грубо говоря,
обрезается список файлов в пакете; поэтому apt не может вычислить weak
provides по путям.

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

Выскажу крамольную точку зрения: не обращайте внимания на фриз.
Если есть желание сделать что-то правильное, делайте сразу.

Дело в том, что java пакеты -- довольно специфическая вещь, они
образуют свой такой маленький мир.  Остальному фризу от них более-менее
ни шатко ни валко.  Кое-кто в них даже ничего не понимает.

> Считаю, что гораздо важнее сейчас добиться совместимости с 
> JPackage, чтобы пользователь мог просто добавить в 
> /etc/apt/sources.list
> rpm     [JPackage] MIRROR VERSION/generic free
> rpm-src [JPackage] MIRROR VERSION/generic free non-free
> и мог свободно обновляться прямо с JPackage.

Вы могли бы в двух словах пояснить, что такое JPackage?
То есть предлагается просто чужие rpm'ы устанавливать на сизиф?

Ну, думаю, что по policy чужие пакеты в сизиф никак не пройдут.
А если кто-то будет просто использовать это в частном порядке...

> Обоснование:
> -0------------------------------------------
> Сейчас в ALT только 2 человека (я и Дамир) занимаются java,
> и 2-м человекам просто не под силу *качественно* поддерживать 
> те же 150 альтовских пакетов (тем более те же 550 пакетов 
> Jpackage). 
> Я вижу разумный выход в достижении такого уровня совместимости с 
> JPackage, когда разработчик мог бы сосредоточиться на небольшом числе 
> ключевых пакетов, а остальные пакеты механически импортировались бы 
> (например, скриптом) из JPackage, добавляя в спек любые Альтовские 
> фенечки, которые захотим добавить. 
> Так все (RH,Fedora,Mandriva,...) и делают.
> -0------------------------------------------

Трудно судить.  С одной стороны, Вы пишете, что джавой в сизифе
занимается всего два человека; с другой стороны, у Вас просматривается
пресуппозиция востребованности 150 или даже 500 джавовских пакетов.
Эта пресуппозиция кажется мне необоснованной.  Что если Вы будете
собирать только те джавовские пакеты, которые Вы используете и можете
протестировать?

> Генерирование Provides: специального вида java(xalan-j)
> (в отличие от Requires:) такую совместимость сломают,
> почему я и предлагал генерировать зависимости на файлы
> вида
> Requires: /usr/share/java/xalan-j.jar

В первых строках, по-видимому, ошибка.  Provides никакой
совместимости сломать не сможет, а вот Requires сможет.
С другой стороны, вопрос совместимости -- топологический.
Если все базовые пакеты собраны с "расширенными" зависимостями,
то у инородных contrib пакетов совместимость не ломается.
То есть мы как бы идем от нижней грани к верхней грани решетки...
Ну, не буду смешить Вас своими представлениями об этом деле.

> Теперь предлагаю (из-за проблем с apt) пойти еще дальше и
> генерировать тогда уже зависимости на имя пакета:
> вида
> Requires: xalan-j
> (но только после релиза 3.1)
> :) 

Вы фактически предлагаете избегать виртуальные зависимости.
Я не думаю, что это правильно.

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

Над этим надо подумать.  Я бы попытался помочь, но сейчас я в этом
ничего не понимаю.  К тому же в ближайшие несколько дней меня не будет.

> Dr. Igor Vlasenko

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 20:55 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-19 5:31 UTC (permalink / raw)]

[devel] ant

[@ 2007-02-22 16:19 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 10:00 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 9:42 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 18:15 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 9:24 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 9:34 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 9:55 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 10:18 UTC (permalink / raw)]

Re: [devel] Java autoreq/autoprov draft

[@ 2007-02-15 10:24 UTC (permalink / raw)]