ALT Linux Bugzilla – #18456

Зависимости прописываются AutoReq. Какую из них ты считаешь дикой?

Например, ant или java-1.6.0-sun-devel, или eclipse-jdt.

AutoReq не безгрешен :)

Для интереса заглянул в Debian, там зависимости такие:

Depends: j2re1.4 | java2-runtime, j2re1.4 | java-virtual-machine
Recommends: mozilla-browser | www-browser

osgi(org.apache.ant) -> eclipse-platform
osgi(org.junit) -> eclipse-jdt

Эти двое и вытягиивают весь этот bloat.  А eclipse сейчас официально сломан.

apt-cache show freemind
...
Depends: java (>= 1.5.0), /bin/sh, coreutils, grep, osgi(org.apache.ant), osgi(org.junit), rpm

Я не знаю откуда вытягивается org.apache.ant и не умею искать так, чтобы эот найти.

AutoReq: yes,noosgi поможет сдуть этот bloat.
В jar присутствует OSGi манифест,
но соответствующие provides есть только в рамках eclipse platform.

(In reply to comment #5)
> AutoReq: yes,noosgi поможет сдуть этот bloat.
> В jar присутствует OSGi манифест,
> но соответствующие provides есть только в рамках eclipse platform.
А проблема-то в чём? osgi manifest неверно заполнен?

> А проблема-то в чём? osgi manifest неверно заполнен?

Основная проблема - сторонний ./plugins/script/groovy-all-1.5.6.jar,
в котором эти зависимости прописанны.
Впрочем, там зависимости опциональные, 
Require-Bundle: org.apache.ant;resolution:=optional, org.junit;resolution:=optional
поэтому достаточно просто пересобрать пакет, новый osgi.req
пропускает опциональные Require-Bundle:.

Напомню, что согласно http://www.altlinux.org/JavaPolicy
Использование сторонних бинарных сборок крайне не рекомендуется.

Крайне не рекомендуется использование бинарных кодов, взятых откуда либо кроме Сизифа.

    * Пакеты должны собираться из исходных текстов, если это позволяет лицензия. 

Если пакет не собран из исходных текстов, а инсталлирует готовый jar, несмотря на присутствие исходных текстов, то лучше его в Сизиф не класть (но можно положить в Дедал в ожидании доработки).

    * Пакеты не должны использовать при сборке чужие библиотеки. 

Очень часто вместе с исходными текстами идут готовые собранные сторонние библиотеки. Пакеты не должны использовать при сборке эти готовые сторонние собранные библиотеки, а должны использовать вместо них библиотеки, собранные в Сизифе. Если какой-то готовой сторонней собранной библиотеки в Сизифе нет, ее необходимо сначала туда собрать. 

Можно для начала попробовать groovy11-all-1.1.jar из Сизифа.
И кроме groovy там еще куча сторонних библиотек запакована.

вдогонку: Там надо BuildArch: noarch.
 

(In reply to comment #7)
> > А проблема-то в чём? osgi manifest неверно заполнен?
> 
> Основная проблема - сторонний ./plugins/script/groovy-all-1.5.6.jar,
Да, действительно, там много идущих jar-файлов...

...
> поэтому достаточно просто пересобрать пакет, новый osgi.req
> пропускает опциональные Require-Bundle:.
Это уже радует.

> Напомню, что согласно http://www.altlinux.org/JavaPolicy
> Использование сторонних бинарных сборок крайне не рекомендуется.
Я думаю, что в этом полиси не хватает обоснования такой рекомендации.
 
>     * Пакеты должны собираться из исходных текстов, если это позволяет
> лицензия. 
Правильно ли я понимаю 
http://www.altlinux.org/Java/HOWTO
мне надо заместить jar-файлы из freemind поставляемыми в Сизифе с помощью ссылки на $(build-classpath)?

... 
> Можно для начала попробовать groovy11-all-1.1.jar из Сизифа.
> И кроме groovy там еще куча сторонних библиотек запакована.
Способ поиска jar-файлов предполагает указания полного пути к нему,
то есть просто удалить такие файлы нельзя, верно?

(In reply to comment #9)
> мне надо заместить jar-файлы из freemind поставляемыми в Сизифе с помощью ссылки
> на $(build-classpath)?

да.

> Способ поиска jar-файлов предполагает указания полного пути к нему,
> то есть просто удалить такие файлы нельзя, верно?
да. 
Более того, проще симлинки делать с в точности такими же именами,
чтобы не связываться  с редактированием.

можно, конечно, набросать симлинков в /usr/share/freemind/lib
и сказать -classpath '/usr/share/freemind/lib/*' 
"загрузить все jar из /usr/share/freemind/lib"
Но это если серьезно отредактировать /usr/bin/freemind.
там сейчас вручную набирается
CLASSPATH="${ADD_JARS}:${CLASSPATH}:${freedir}/lib/freemind.jar:\
${freedir}/lib/jibx/jibx-run.jar:\
${freedir}/lib/jibx/xpp3.jar:\
${freedir}/lib/bindings.jar:\
${freedir}/lib/commons-lang-2.0.jar:\
${freedir}/lib/forms-1.0.5.jar:\
${freedir}"
итд.

(In reply to comment #10)
> (In reply to comment #9)
> > мне надо заместить jar-файлы из freemind поставляемыми в Сизифе с помощью ссылки
> > на $(build-classpath)?
> 
> да.

Точнее, сначала хотя бы то, что пройдет.
сторонние jar в freemind - смесь от устаревших версий
(которых уже нет в Сизифе) до новейших (которых еще нет в Сизифе).
Могут проявиться проблемы совместимости.
А могут и не проявиться.

(In reply to comment #11)
...
> сторонние jar в freemind - смесь от устаревших версий
> (которых уже нет в Сизифе) до новейших (которых еще нет в Сизифе).
> Могут проявиться проблемы совместимости.
Что-то вот я не понимаю вашего совета. Вы предлагаете заменить те библиотеки, с которыми freemind гарантированно работает, на другие, версий то меньше, то больше, и расхлёбывать получившееся? А если он сломается?

> > сторонние jar в freemind - смесь от устаревших версий
> > (которых уже нет в Сизифе) до новейших (которых еще нет в Сизифе).
> > Могут проявиться проблемы совместимости.
> Что-то вот я не понимаю вашего совета. Вы предлагаете заменить те
> библиотеки, с которыми freemind гарантированно работает, на другие, версий то
> меньше, то больше, и расхлёбывать получившееся? 

Да.

Java - порождение корпоративного мира. 
Многие ее уродливые черты напоминают такие же в Windows.
И можно ее отрицать и ненавидеть в целом, а можно сквозь
уродство и безобразие дистиллировать ее капля за каплей
в нечто правильное. Как wine делает это с Windows :)


А если он сломается?
Как правило, вылезет API несовместимость, т. е.
скорее не соберется, чем сломается.
Если сломается, то можно откатить. 

Если не сломается, мир станет на каплю лучше :)

Пора покончить с этим уродливым явлением -
апстримом распространяется IM клиент на java: собственного кода 1M, 
дублей имеющихся библиотек на 50M
и еще для полноты счастья набор jre под все архитектуры
еще 70М.

1-2 java программы занимают места больше, чем Linux LiveCD с OpenOffice :(

(In reply to comment #13)
> > Вы предлагаете заменить те
> > библиотеки, с которыми freemind гарантированно работает, на другие, версий то
> > меньше, то больше, и расхлёбывать получившееся? 
> 
> Да.

Хотя бы часть библиотек.

Теперь лучше?
$ rpm --requires -qp freemind-0_9_0-alt3.rc1.noarch.rpm
java >= 1.5.0
coreutils
grep
groovy
jakarta-commons-lang

Я бы не сказал, что особо лучше... но видимо это предел...
$ agi freemind
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  adaptx ant ant-junit asm asm2 axion backport-util-concurrent bcel bea-stax bea-stax-api bsf castor0 cglib dom4j excalibur excalibur-avalon-logkit
  geronimo-ejb-2.1-api geronimo-j2ee-1.4-apis geronimo-j2ee-connector-1.5-api geronimo-jms-1.1-api geronimo-jta-1.0.1B-api geronimo-servlet-2.4-api
  gnu-crypto-sasl-jdk1.4 gnu-regexp groovy hsqldb icu4j isorelax jakarta-commons-codec jakarta-commons-el jakarta-commons-fileupload jakarta-commons-httpclient
  jakarta-commons-lang jakarta-commons-primitives jakarta-commons-transaction jakarta-oro jakarta-slide-webdavclient jarjar java-1.6.0-sun-devel jaxen jdom jettison
  jetty5 jetty5-javadoc jmock joda-time junit ldapsdk log4j mockobjects msv msv-xsdlib mx4j nekohtml openejb1 qdox radeox relaxngDatatype servletapi4 sun-jaf
  sun-mail tomcat5-jasper tomcat5-jsp-2.0-api tomcat5-servlet-2.4-api tomcat6-servlet-2.5-api velocity werken-xpath ws-jaxme wstx xalan-j2 xerces-j2 xml-commons
  xml-commons-jaxp-1.2-apis xml-commons-jaxp-1.3-apis xml-commons-resolver12 xml-im-exporter xmldb-api xmldb-api-sdk xom xpp2 xpp3 xstream

Думаю, дальше можно вешать багу на 
$ rpm --requires groovy
ant
ant-junit
antlr
asm2
axion
bsf
cglib
jakarta-commons-cli
jakarta-commons-codec
jakarta-commons-collections
jakarta-commons-httpclient
jakarta-commons-logging
jakarta-commons-primitives
jakarta-oro
jarjar
jmock
junit
mockobjects
mx4j
nekohtml
openejb1
qdox
radeox
regexp
tomcat5-jsp-2.0-api
tomcat5-servlet-2.4-api
xerces-j2
xml-commons-jaxp-1.3-apis
xpp3
xstream
jpackage-utils >= 0:1.7.4
jpackage-utils >= 0:1.7.4

(In reply to comment #17)
> Думаю, дальше можно вешать багу на 
> $ rpm --requires groovy
> ...

groovy -- это целый язык для java virtual machine,
все эти библиотеки, вообще говоря, используются.

Это то же самое, если gnomer/gtkшник поставил
себе какой-нибудь kfurfurrent, а тот ему пол kde в систему втянул.

Никто же по этому поводу не ругается и не предлагает
линковать kfurfurrent с qt4 и kde libs статически.

Се ля ви.

(In reply to comment #18)
> groovy -- это целый язык для java virtual machine,
> все эти библиотеки, вообще говоря, используются.
Вам виднее. Мне казалось, apt нужен только при сборке.

(In reply to comment #19)
> Вам виднее. Мне казалось, apt нужен только при сборке.

конечно, для работы freemind
этого добра не нужно.

Это похоже на то, когда программе нужно
пара вызовов из libqucktime.so
а пакет libqucktime тянет (и реально слинкован с)
ffmpeg, libjpeg, x264 и тд. 20 доп. библиотеками :(

тогда мне наверное проще отказаться от freemind...

*** Bug 20184 has been marked as a duplicate of this bug. ***