Re: [devel] Java autoreq/autoprov draft

[Alexey Tourbin <at@altlinux.ru>]

[-- 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 --]