[devel] Java autoreq/autoprov draft

[devel] Java autoreq/autoprov draft

[@ 2007-02-06 22:21 UTC (permalink / raw)]

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

[Igor Vlasenko]

On Thu, 15 Feb 2007, Alexey Tourbin wrote:                                      
> Вы могли бы в двух словах пояснить, что такое JPackage?                       
                                                                                
http://jpackage.org/ -- Аналог сизифа для жавы в Линуксе.                       
хорошая презентация http://jpackage.org/JPackage3.pdf                           
                                                                                
"The JPackage Project has two primary goals:                                    
                                                                                
    * To provide a coherent set of Java software packages for                   
Linux, satisfying all quality requirements of other applications.               
    * To establish an efficient and robust policy for Java                      
software packaging and installation." 
"Our RPMs are generic in that they should work on any RPM based                 
Linux distribution (Mandriva, Red Hat, SuSE, others). Other                     
packaging format suggestions are welcome too."                                  
                                                                                
> То есть предлагается просто чужие rpm'ы устанавливать на сизиф?               
Главное, это совместимость полиси, чтобы их импорт был                          
тривиальным. Что касается установки их rpm,                                     
иметь такую возможность при желании, как следствие совместимости                
с JPackage, было бы удобно для пользователей,                                   
в случае, если Сизиф будет отставать.

> Трудно судить.  С одной стороны, Вы пишете, что джавой в сизифе               
> занимается всего два человека; с другой стороны, у Вас просматривается        
> пресуппозиция востребованности 150 или даже 500 джавовских пакетов.           
> Эта пресуппозиция кажется мне необоснованной.  Что если Вы будете             
> собирать только те джавовские пакеты, которые Вы используете и можете         
> протестировать?                                                               
                                                                                
Это проблема зависимостей. Как клубника на огороде ---                          
пол дня поедания требуют пол года пропалывания.                                 
                                                                                
У жавы хорошая повторная испоьзуемость, при том из системы она                  
ничего не берет, ищет свое (платформонезависимость).                            
Поэтому, чтобы собрать 1 нужное, нужно собрать 50 "ненужного".                  
Пример на http://wiki.sisyphus.ru/JBoss,                                        
где описан роман-эпопея "сборка JBoss для Сизиф". 

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

если пишут Provides, то чтобы удоволетворить чьи-то Requires... 
Фразой "Provides  сломает совместимость" хотел сказать, что                     
обновить альтовский пакет до пакета из JPackage                                 
apt'ом не удастся, так как в нем не будет специальных Provides                  
и обновление породит тогда unmets.                                              
                                                                                
Совместимость с JPackage хороша тем, что если                                   
java в Сизифе будет опять заброшена, на пользователях это не                    
отразится. Опять же, backports. без усилий имеем самую свежую                   
noarch жаву для любого устаревшего дистрибутива.                                
Исключение только arch сbорки вроде eclipse.

> Вы фактически предлагаете избегать виртуальные зависимости.                   
> Я не думаю, что это правильно.                                                
                                                                                
Я просто прошу с ними повременить до момента, когда                             
будет налажен импорт из jpackage.                                               
Тогда это будет механизмом контроля качества. а часть                           
совместимости можно будет и принести в жертву --- возможному                    
выигрышу в качестве. Она уже не будет такой нужной,                             
ведь регулярный импорт будет                                                    
гарантировать отсутствие разницы между jpackage и Сизифом.
                                                                                
--                                                                              
Dr. Igor Vlasenko                                                               
---------------------                                                           
vlasenko@imath.kiev.ua                                                          
=====================                                                           
Topology department                                                             
Institute of Math                                                               
Kiev, Ukraine                                                                   
 

Re: [devel] Java autoreq/autoprov draft

[Eugene Prokopiev]

> Поэтому, чтобы собрать 1 нужное, нужно собрать 50 "ненужного".                  
> Пример на http://wiki.sisyphus.ru/JBoss,                                        
> где описан роман-эпопея "сборка JBoss для Сизиф". 

Справедливости ради следует сказать, что подобный способ сборки - это 
патология, сравните с процедурой сборки Geronimo. В большинстве случаев 
для сборки больших систем с кучей зависимостей используется maven - в 
некотором смысле аналог нашего hasher.

-- 
С уважением, Прокопьев Евгений

[devel] ant

[Igor Vlasenko]

Дамир,
извините,
Вы смотрели https://bugzilla.altlinux.org/show_bug.cgi?id=10857
?
Если хотите, добавьте меня в список и я выложу обновление.
Также как там с jpackage-utils? 
Тоже, если Вы загружены, могу выложить.
Они мне нужны чтобы безопасно выложить обновление j2se1.5.
Чтобы быть уверенным, что сборка openoffice не сломается.

-- 

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

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

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

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

rpm считает все файлы в пакете как бы одноименным provides.  Т.е. rpm
поставит пакет с зависимостью на /asdf/zxcv, если в системе (или в
текущей транзакции на установку) существует пакет с файлом /asdf/zxcv.

К несчастью, у нас сейчас генерируются обрезанные хеши для сизифа,
и apt, в отличие от rpm, не сможет разрешить зависимость на /asdf/zxcv.
Насколько я помню, legion считал такое обрезание хешей делом богоугодным.

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

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

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

On Wed, Feb 07, 2007 at 11:37:49AM +0600, Ildar Mulyukov wrote:
> Осталось это всё оформить в виде /usr/lib/rpm/{prov,req}.java ,  
> положить в rpm-build-java и повесить FR на пакет rpm-build (я и сам  
> прошёл этот путь).

rpm-build можно не модифицировать (т.к. скритпы /usr/lib/find-requires и
/usr/lib/find-provides жутко не модульные), а достигнуть модульности с
помощью своеобразного chaining.  Я реализовал такую схему в
rpm-build-fpc.  Когда используется любой специфический %fpc_* макрос,
значение %__find_requires = /usr/lib/rpm/find-requires
автоматически заменяется на
%__find_requires = /usr/lib/rpm/fpc.req %__find_requires
т.е. впереди старого значения дописывается новый скрипт-обертка, который
вычисляет специфические зависимости и потом вызывает "стандартный"
find-requires.  Понятно, что таким макаром можно прозрачно сделать как
бы curring, т.е. использовать две и более обертки: первая обертка
вычисляет специфические зависимости и вызывает вторую обертку и т.д.,
а последнаяя обертка будет вызывать стандартный find-requires.

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

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

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

On Thu, Feb 15, 2007 at 12:42:12PM +0300, Alexey Tourbin wrote:
> On Wed, Feb 07, 2007 at 11:37:49AM +0600, Ildar Mulyukov wrote:
> > Осталось это всё оформить в виде /usr/lib/rpm/{prov,req}.java ,  
> > положить в rpm-build-java и повесить FR на пакет rpm-build (я и сам  
> > прошёл этот путь).
> 
> rpm-build можно не модифицировать (т.к. скритпы /usr/lib/find-requires и
> /usr/lib/find-provides жутко не модульные), а достигнуть модульности с
> помощью своеобразного chaining.  Я реализовал такую схему в
> rpm-build-fpc.  Когда используется любой специфический %fpc_* макрос,
> значение %__find_requires = /usr/lib/rpm/find-requires
> автоматически заменяется на
> %__find_requires = /usr/lib/rpm/fpc.req %__find_requires
> т.е. впереди старого значения дописывается новый скрипт-обертка, который
> вычисляет специфические зависимости и потом вызывает "стандартный"
> find-requires.  Понятно, что таким макаром можно прозрачно сделать как
> бы curring, т.е. использовать две и более обертки: первая обертка
     currying

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

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

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

On Wed, Feb 07, 2007 at 01:21:37AM +0300, Damir Shayhutdinov wrote:
> > А разве нельзя залезать в .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 файлов находящихся в них.

То есть предлагается ставить только такие зависимости Requires, которые
заведомо удовлетворены в сборочной среде?  Сомнительно.

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

Re: [devel] Java autoreq/autoprov draft

[Damir Shayhutdinov]

> > Для этого надо сначала пройтись по всем .jar файлам в /usr/share/java
> > и составить списки всех .class файлов находящихся в них.
>
> То есть предлагается ставить только такие зависимости Requires, которые
> заведомо удовлетворены в сборочной среде?  Сомнительно.
Угу, я тоже об этом думал. К сожалению, если хочется делать
зависимости на уровне .jar - это единственный выход.

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

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

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

On Thu, Feb 15, 2007 at 12:34:41PM +0300, Damir Shayhutdinov wrote:
> > > Для этого надо сначала пройтись по всем .jar файлам в /usr/share/java
> > > и составить списки всех .class файлов находящихся в них.
> >
> > То есть предлагается ставить только такие зависимости Requires, которые
> > заведомо удовлетворены в сборочной среде?  Сомнительно.
> Угу, я тоже об этом думал. К сожалению, если хочется делать
> зависимости на уровне .jar - это единственный выход.

Здесь выполняется (причем не совсем корректно) часть работы, которую 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-файлов.

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

Re: [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 такое?
Если потянет - то я готов это сделать.

Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin]

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

> > Если я правильно понимаю, что *.jar -- это просто архивы *.class файлов,
> > причем "на самом деле" зависимости существуют именно между *.class
> > файлами; то, по-моему, лучше делать зависимости на уровне class-файлов.
> Угу, просто их количество исчисляется десятками и сотнями. Потянет rpm такое?
> Если потянет - то я готов это сделать.

Потянет.  Всё-таки класс -- довольно высокий уровень абстракции; речь
ведь не идет о том, чтобы учитывать в зависимостях методы класса и т.п.

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