[devel] Q: разруливание сборочных зависимостей в hasher

[devel] Q: разруливание сборочных зависимостей в hasher

[Vladimir Lettiev]

Добрый вечер.

Возник такой вопрос. Какие существуют методы разруливания ситуации, 
когда есть два пакета, которые ссылаются друг на друга в BuildReq? 
Причём готовых rpm этих пакетов ещё нет.

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[devel] Re: Q: разруливание сборочных зависимостей в hasher

[Michael Shigorin]

On Wed, Sep 08, 2004 at 09:12:18PM +0400, Vladimir Lettiev wrote:
> Возник такой вопрос. Какие существуют методы разруливания
> ситуации, когда есть два пакета, которые ссылаются друг на
> друга в BuildReq?  Причём готовых rpm этих пакетов ещё нет.

Бутстрапить укладыванием одного в репозиторий с genbasedir?
(потом предупредить incoming@)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Q: разруливание сборочных зависимостей в hasher

[Vladimir Lettiev]

Michael Shigorin пишет:
> On Wed, Sep 08, 2004 at 09:12:18PM +0400, Vladimir Lettiev wrote:
> 
>>Возник такой вопрос. Какие существуют методы разруливания
>>ситуации, когда есть два пакета, которые ссылаются друг на
>>друга в BuildReq?  Причём готовых rpm этих пакетов ещё нет.
> 
> Бутстрапить укладыванием одного в репозиторий с genbasedir?
> (потом предупредить incoming@)
> 

Что значит "бутстрапить"?

Я примерно понял, что в любом случае нужен уже готовый rpm одного из 
пакетов. Но он может установиться только по --nodeps (эти пакеты также 
имеют друг друга в секции Requires :( ) . И даже если сделать 
репозиторий с этим пакетом, то как hasher (использующий apt) поставит 
его без --nodeps?
Даже будучи собранными, что с ними будет в /incoming/?

Являются ли подобные зависимости явной ошибкой или это номальная ситуация?


-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[devel] Re: Q: разруливание сборочных зависимостей в hasher

[Michael Shigorin]

On Thu, Sep 09, 2004 at 07:39:27AM +0400, Vladimir Lettiev wrote:
> Я примерно понял, что в любом случае нужен уже готовый rpm
> одного из пакетов.

Да, я упустил то, что их тоже нет (и взять негде?) :(

> Но он может установиться только по --nodeps (эти пакеты также
> имеют друг друга в секции Requires :( ) . И даже если сделать
> репозиторий с этим пакетом, то как hasher (использующий apt)
> поставит его без --nodeps?  Даже будучи собранными, что с ними
> будет в /incoming/?  Являются ли подобные зависимости явной
> ошибкой или это номальная ситуация?

Если все так завязано -- есть ли смысл разделять их, не проще ли
объединить исходники и собирать в одном пакете -- так пляски при
бутстрапе (сборке пакета A, требующего для сборки пакет B,
который требует для сборки пакет A -- или просто сборке пакета,
собирающегося самим собой) все же упрощаются -- в конце концов,
можно влепить хоть в /usr/local бинарники, с которыми соберется
rpm, который можно установить и с которым, возможно, его же
пересобрать и результат засунуть вручную в hasher/repo.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Q: разруливание сборочных зависимостей в hasher

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [040909 09:25]:
> Если все так завязано -- есть ли смысл разделять их, не проще ли
> объединить исходники и собирать в одном пакете -- так пляски при
> бутстрапе (сборке пакета A, требующего для сборки пакет B,
> который требует для сборки пакет A -- или просто сборке пакета,
> собирающегося самим собой) все же упрощаются -- в конце концов,
Не проще, точнее не совсем проще.  mingw32-gcc для сборки хочет
mingw32-runtime и mingw32-binutils, mingw32-runtime для сборки
хочет mingw32-binutils и mingw32-gcc.  Класть runtime в один
пакет с gcc - ОЧЕНЬ накладно.

При первой сборке gcc я его бутстрапил то ли сорцами runtime, то
ли прекомпилёными бинарями с mingw.org.  Один раз.

binutils, gcc+bootstrap, runtime, gcc.

Вот только собирал я всё в локальном сандмане, как это будет
выглядеть в /incoming/ - не представляю...

-- 
Regards, Sir Raorn.
-------------------
Zerg, пересобери этот скрипт [/usr/bin/startkde] без использования
-funroll-all-loops, пожалуйста. :)
		-- ldv in devel@

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

[devel] Re: Q: разруливание сборочных зависимостей в hasher

[Michael Shigorin]

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

On Thu, Sep 09, 2004 at 10:06:56AM +0400, Alexey I. Froloff wrote:
> Вот только собирал я всё в локальном сандмане, как это будет
> выглядеть в /incoming/ - не представляю...

С другой стороны, в недавно пробегавшем объяснении фигурировало
упоминание бутстрапов как особого случая без пояснений.

Видимо, от случая к случаю решение зависит и, в частности, могут
быть опубликованы бинарники от проверенного майнтейнера?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: Q: разруливание сборочных зависимостей в hasher

[Ivan Fedorov]

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

Michael Shigorin пишет:
> On Thu, Sep 09, 2004 at 10:06:56AM +0400, Alexey I. Froloff wrote:
> 
>>Вот только собирал я всё в локальном сандмане, как это будет
>>выглядеть в /incoming/ - не представляю...
> 
> 
> С другой стороны, в недавно пробегавшем объяснении фигурировало
> упоминание бутстрапов как особого случая без пояснений.
> 
> Видимо, от случая к случаю решение зависит и, в частности, могут
> быть опубликованы бинарники от проверенного майнтейнера?
А зачем? IMHO эти бинарники надо просто засунуть в hasher repo и сделать
2-3 пересборки в зависимости от количества пакетов.

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

Re: [devel] Re: Q: разруливание сборочных зависимостей в hasher

[Vladimir Lettiev]

Michael Shigorin wrote:
>>Но он может установиться только по --nodeps (эти пакеты также
>>имеют друг друга в секции Requires :( ) . И даже если сделать
>>репозиторий с этим пакетом, то как hasher (использующий apt)
>>поставит его без --nodeps?  Даже будучи собранными, что с ними
>>будет в /incoming/?  Являются ли подобные зависимости явной
>>ошибкой или это номальная ситуация?
> 
> Если все так завязано -- есть ли смысл разделять их, не проще ли
> объединить исходники и собирать в одном пакете

Вот! Объединение исходников - самый лучший вариант здесь.


Вобщем-то я залез на jakarta.apache.org и почувствовал, что попал в 
другое измерение. срочно надо поднять tomcat(4|5|5.5)?, а что это такое 
разбираюсь по ходу дела. Очень не хватает полноценной поддержки java в 
Sisyphus. Чтобы подобраться к самому tomcat надо выложить немаленькую 
кучку пакетиков.
После иccледования jpackage.org пришёл к выводу, что такое дробление и 
взаимо-,само- зависимости неприемлемы, хотя в целом java policy там 
просто замечательная.

Мысли по ходу дела:
* В java-common(-devel?) неплохо бы запихнуть макросы для rpm для 
использования в других java-пакетах.
* в rpm GROUPS одинокая Development/Java -- может расширить?


-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[devel] Q: java development

[Vladimir Lettiev]

Vladimir Lettiev пишет:
> 
> Вобщем-то я залез на jakarta.apache.org и почувствовал, что попал в 
> другое измерение. срочно надо поднять tomcat(4|5|5.5)?, а что это такое 
> разбираюсь по ходу дела. Очень не хватает полноценной поддержки java в 
> Sisyphus. Чтобы подобраться к самому tomcat надо выложить немаленькую 
> кучку пакетиков.
> После иccледования jpackage.org пришёл к выводу, что такое дробление и 
> взаимо-,само- зависимости неприемлемы, хотя в целом java policy там 
> просто замечательная.
> 
> Мысли по ходу дела:
> * В java-common(-devel?) неплохо бы запихнуть макросы для rpm для 
> использования в других java-пакетах.
> * в rpm GROUPS одинокая Development/Java -- может расширить?
> 

тема java-пакетов как-то игнорируется разработчиками. Толи никому они не 
нужны, толи никто в этом вопросе не сведует, толи и то и другое. А ведь 
собрав хотя бы небольшой базовый репозиторий можно заполучить такие 
вкусные вещи как tomcat, eclipse, open-xchange...

собрав пачку пакетов я обнаружил, что rpm не находит никаких 
зависимостей для них. Впрочем это понятно, зависимости perl-программ 
ищет rpm-build-perl, а python'ьи - rpm-build-python. А для java никто 
ещё не написал парсера.

не хватает хорошего java-devel. Куда бы можно было запихать rpm-макросы, 
скрипты поиска нужных jar'ов. Если мне его собрать, то он будет 
пересекаться частично с java-common...

руки чешутся начать сливать в /incoming/ всё собранное хозяйство, но 
думаю надо сначало обсудить с заинтересованными хоть какие-нибудь 
аспекты java-policy в Sisyphus.

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re: [devel] Q: java development

[Вячеслав Диконов]

On Птн, 2004-09-10 at 14:33 +0400, Vladimir Lettiev wrote:
> тема java-пакетов как-то игнорируется разработчиками. Толи никому они не 
> нужны, толи никто в этом вопросе не сведует, толи и то и другое. А ведь 
> собрав хотя бы небольшой базовый репозиторий можно заполучить такие 
> вкусные вещи как tomcat, eclipse, open-xchange...

> руки чешутся начать сливать в /incoming/ всё собранное хозяйство, но 
> думаю надо сначало обсудить с заинтересованными хоть какие-нибудь 
> аспекты java-policy в Sisyphus.
Я жду Java чтобы собрать OmegaT. Мне нужен пример сборки java-пакета и
налаженная поддержка java в Сизифе.  
-- 
Вячеслав Диконов <sdiconov@mail.ru>

Re: [devel] Q: java development

[Vladimir Lettiev]

Вячеслав Диконов wrote:
> On Птн, 2004-09-10 at 14:33 +0400, Vladimir Lettiev wrote:
> 
>>тема java-пакетов как-то игнорируется разработчиками. Толи никому они не 
>>нужны, толи никто в этом вопросе не сведует, толи и то и другое. А ведь 
>>собрав хотя бы небольшой базовый репозиторий можно заполучить такие 
>>вкусные вещи как tomcat, eclipse, open-xchange...
> 
> 
>>руки чешутся начать сливать в /incoming/ всё собранное хозяйство, но 
>>думаю надо сначало обсудить с заинтересованными хоть какие-нибудь 
>>аспекты java-policy в Sisyphus.
> 
> Я жду Java чтобы собрать OmegaT. Мне нужен пример сборки java-пакета и
> налаженная поддержка java в Сизифе.  

примеры сборки я брал с jpackage.org, mandrake cooker, fedor'овский 
tomcat смотрел. И потом сравнил это с тем, что имеется в Sisyphus. 
Остался при мнении, что jpackage представляет наиболее сильное и удачное 
policy. Именно поэтому cooker интегрировал сборки jpackage к себе. Да и 
вообще там есть сборки для Fedora, RedHat, RedHat ES, Mandrake и даже 
Solaris. Единственное смущают просто дубовые зависимости в спеках из-за 
слишком сильного дробления исходников по разным src.rpm.

Полиси у них опубликовано в пакете jpackage-utils: 
http://mirrors.sunsite.dk/jpackage/1.5/generic/free/SRPMS/jpackage-utils-1.5.38-1jpp.src.rpm

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[devel] Re: Q: java development

[Michael Shigorin]

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

On Fri, Sep 10, 2004 at 02:33:31PM +0400, Vladimir Lettiev wrote:
> > Очень не хватает полноценной поддержки java в Sisyphus.
> тема java-пакетов как-то игнорируется разработчиками.

Я-то надеялся, что Алексей Боровской доберется до Вашего
сообщения -- но, кажется, он обитает в sisyphus@.

Просмотрите:

http://lists.altlinux.ru/pipermail/sisyphus/2003-October/029268.html
http://lists.altlinux.ru/pipermail/sisyphus/2004-June/042086.html
http://lists.altlinux.ru/pipermail/sisyphus/2004-July/043570.html
http://people.altlinux.ru/~mhz/software/SRPMS/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: Q: java development

[Genix]

Michael Shigorin wrote:

>>>Очень не хватает полноценной поддержки java в Sisyphus.
>>>      
>>>
>>тема java-пакетов как-то игнорируется разработчиками.
>>    
>>
>
>Я-то надеялся, что Алексей Боровской доберется до Вашего
>сообщения -- но, кажется, он обитает в sisyphus@.
>  
>
Я не понял ситуации, но Алексей Боровский не ответил ни на одно мое 
письмо в личное или в рассылку. Причину молчания он тоже не объяснил

-- 
У каждого в башке свои тараканы...

Re: [devel] Q: java development

[Aleksey Novodvorsky]

Vladimir Lettiev пишет:

> Vladimir Lettiev пишет:
>
>>
>> Вобщем-то я залез на jakarta.apache.org и почувствовал, что попал в 
>> другое измерение. срочно надо поднять tomcat(4|5|5.5)?, а что это 
>> такое разбираюсь по ходу дела. Очень не хватает полноценной поддержки 
>> java в Sisyphus. Чтобы подобраться к самому tomcat надо выложить 
>> немаленькую кучку пакетиков.
>> После иccледования jpackage.org пришёл к выводу, что такое дробление 
>> и взаимо-,само- зависимости неприемлемы, хотя в целом java policy там 
>> просто замечательная.
>>
>> Мысли по ходу дела:
>> * В java-common(-devel?) неплохо бы запихнуть макросы для rpm для 
>> использования в других java-пакетах.
>> * в rpm GROUPS одинокая Development/Java -- может расширить?
>>
>
> тема java-пакетов как-то игнорируется разработчиками. Толи никому они 
> не нужны, толи никто в этом вопросе не сведует, толи и то и другое. А 
> ведь собрав хотя бы небольшой базовый репозиторий можно заполучить 
> такие вкусные вещи как tomcat, eclipse, open-xchange...

Базовый уже есть в Sisyphus. j2se, ant, junit.
И hasher ldv чинил для сборки этих пакетов.

>
> собрав пачку пакетов я обнаружил, что rpm не находит никаких 
> зависимостей для них. Впрочем это понятно, зависимости perl-программ 
> ищет rpm-build-perl, а python'ьи - rpm-build-python. А для java никто 
> ещё не написал парсера.
>
> не хватает хорошего java-devel. Куда бы можно было запихать 
> rpm-макросы, скрипты поиска нужных jar'ов. Если мне его собрать, то он 
> будет пересекаться частично с java-common...
>
> руки чешутся начать сливать в /incoming/ всё собранное хозяйство, но 
> думаю надо сначало обсудить с заинтересованными хоть какие-нибудь 
> аспекты java-policy в Sisyphus.
>
Давайте обсуждать.

Rgrds, Алексей

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

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

Michael Shigorin wrote:
> On Fri, Sep 10, 2004 at 02:33:31PM +0400, Vladimir Lettiev wrote:
> 
>>>Очень не хватает полноценной поддержки java в Sisyphus.
>>
>>тема java-пакетов как-то игнорируется разработчиками.
> 
> 
> Я-то надеялся, что Алексей Боровской доберется до Вашего
> сообщения -- но, кажется, он обитает в sisyphus@.
> 
> Просмотрите:
> 
> http://lists.altlinux.ru/pipermail/sisyphus/2003-October/029268.html
> http://lists.altlinux.ru/pipermail/sisyphus/2004-June/042086.html
> http://lists.altlinux.ru/pipermail/sisyphus/2004-July/043570.html
> http://people.altlinux.ru/~mhz/software/SRPMS/
> 

Видел я это всё (google кипел под напором моего браузера) , и те 
сообщения, что alb не отвечает на личную почту. Такие же вопросы 
возникли по именованию jar-ов. Поэтому и не тороплюсь выкладывать то, 
что собрал - у меня почти такой же список собранного. А ведь Алексей, в 
отличии от меня, не вчера узнал что такое java.

Поскольку я привлёк публику, то думаю, что пора объясняться.
В атаче лежит java-полиси проекта jpackage.org. Я хотел изложить свои 
мысли, но они полностью совпали с этим полиси. Правда чтобы оно 
заработало надо сделать пакет java-devel, который бы провайдил все 
необходимые макросы и функции (функции AddToClasspath в java-common 
крайне мало).

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[-- Attachment #2: jpackage-utils-policy --]
[-- Type: text/plain, Size: 4411 bytes --]

$Id: jpackage-utils-policy,v 1.1.2.3 2003/08/31 15:49:23 scop Exp $

JPackage packaging policy

Package

Name

The package name, hereafter refered to as %{name}, is the complete
name of the packaged software.

Exception: if it is a requirement that multiple versions of a package
can be installed to a single machine, relevant part of the version
number is appended to complete software name to form the package name.

Package name must contain only lowercase characters.

Version

The package version, hereafter referred to as %{version}, is the
complete version of the packaged software.

Exception: non-numeric version extensions, such as "pre", "rc",
"beta", etc, are prohibited as they may confuse rpm. Instead, these
are included in the package revision.

Exception: when no exact version is available, as in non-tagged CVS
snapshot, use the snapshot date in YYYYMMDD format.

Release 

The package release, hereafter refered to as %{release}, is a strictly
increasing number, followed by specific project jpp tag appended.

Exception: when non-numeric version extensions are used, this number
is preceded by the number 0, a dot, and the version extension to
ensure proper release ordering.

Granularity 

Small is beautiful: prefer several modular subpackages when possible. 

The main package must contain only basic files needed for running the
software, with license agreement and basic documentation files.

Any optional file must be provided as a separate subpackage, with
exact version and release dependency to the main package.

Any demo or sample files must be provided as a separate -demo
subpackage, with exact version and release dependency to the main
package.

Any user manual must be provided as a separate -manual subpackage,
with no special dependency to the main package.

Each Javadoc tree must be provided as a separate -javadoc subpackage,
with no special dependency to the main package.

Sections

free section contains free software.

non-free section contains non-free and non-distributable software.

Dependencies

A free package must avoid optional non-free runtime
dependencies. Build dependencies are needed, however, to ensure proper
build environment.

Files

Locations

Data and demo files must be installed into the standard
/usr/share/%{name} directory.

Javadoc files must be installed into a
/usr/share/javadoc/%{name}-%{version} directory.

Application archives must be installed under the /usr/share/java
directory in the following way:

For simple software with just a few jars, directly to top level.  For
simple software with many jars, into a /usr/share/java/%{name}
directory.  For complex applications, in a /usr/share/java/%{name}
subdirectory with proper internal structure.

Names

The general idea is that given package name, one should be able to
deduce jar name(s): package abcd should contain either a single
/usr/share/java/abcd.jar jar, or multiple /usr/share/java/abcd/*.jar
or /usr/share/java/abcd-*.jar jars.

Main jars stored directly under /usr/share/java must follow naming
pattern %{name}-%{version}.jar.

Secondary jars stored directly under /usr/share/java must follow
naming pattern %{name}-<subpackage>-%{version}.jar.

Jars stored in a /usr/share/java/%{name} subdirectory must follow
naming pattern <subpackage>-%{version}.jar.

All zip format archive must be converted to jar format, and a
compatibility symlink be provided.

All legacy names must be converted to standard names, and a
compatibility symlink be provided if there's substantial difference.

Compatibility symlinks must be versioned too.

For every versioned jar or symlink, a corresponding unversioned
symlink must be provided to allow version independant use.

Granularity
 
Once again, small is beautiful: prefer several modular jars when
possible.

Avoid duplicate classes, and remove redundant jars.

Building 

In order to track source origin, it is preferable to use unmodified
original archives, when available in a form suitable for building.

Never use provided external binaries. Delete them to ensure potential
build interference.

Running

All applications must use a standardized wrapper script, using the
JPackage function library.

All servers must be shipped with usual service script, logrotate
configuration, etc...

Classpath references in MANIFEST files interfere with classpath, are
not configurable, and don't work in JDK 1.1.x. They must be removed.

Re: [devel] Q: java development

[Vladimir Lettiev]

Aleksey Novodvorsky wrote:
> Vladimir Lettiev пишет:
>> тема java-пакетов как-то игнорируется разработчиками. Толи никому они 
>> не нужны, толи никто в этом вопросе не сведует, толи и то и другое. А 
>> ведь собрав хотя бы небольшой базовый репозиторий можно заполучить 
>> такие вкусные вещи как tomcat, eclipse, open-xchange...
> 
> Базовый уже есть в Sisyphus. j2se, ant, junit.

Вот. Это совсем базовый набор. Но слава богу он есть.

> И hasher ldv чинил для сборки этих пакетов.

hasher кушает java-пакеты как конфетки и ещё просит -- моей радости нет 
предела ;-). Вот я и изумляюсь, что до сих пор так мало пакетов.

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re: [devel] Q: java development

[Aleksey Novodvorsky]

Vladimir Lettiev пишет:

> Aleksey Novodvorsky wrote:
>
>> Vladimir Lettiev пишет:
>>
>>> тема java-пакетов как-то игнорируется разработчиками. Толи никому 
>>> они не нужны, толи никто в этом вопросе не сведует, толи и то и 
>>> другое. А ведь собрав хотя бы небольшой базовый репозиторий можно 
>>> заполучить такие вкусные вещи как tomcat, eclipse, open-xchange...
>>
>>
>> Базовый уже есть в Sisyphus. j2se, ant, junit.
>
>
> Вот. Это совсем базовый набор. Но слава богу он есть.
>
>> И hasher ldv чинил для сборки этих пакетов.
>
>
> hasher кушает java-пакеты как конфетки и ещё просит -- моей радости 
> нет предела ;-). Вот я и изумляюсь, что до сих пор так мало пакетов.
>
Ну, там сейчас все пакеты от mhz, -- если уже не так, -- извините. 
Давайте подождем, что скажет Михаил.

Rgrds, Алексей

Re: [devel] Q: java development

[Aleksey Novodvorsky]

Vladimir Lettiev пишет:

> Aleksey Novodvorsky wrote:
>
>> Давайте подождем, что скажет Михаил.
>>
>
> Хорошо, подождём  < "спеши медленно" (C) народная мудрость(?) :) >
>
> Михаил тоже немного неуловим. Сказал недавно в devel@, что в hasher'е 
> до сих пор какие-то проблемы ("странный выбор пакета JDK"), но я с 
> таким пока не сталкивался.
>
Ну, скажем, до вторника подождем. :-)

Rgrds, Алексей

Re: [devel] Q: java development

[Vladimir Lettiev]

Aleksey Novodvorsky wrote:
>>
>> hasher кушает java-пакеты как конфетки и ещё просит -- моей радости 
>> нет предела ;-). Вот я и изумляюсь, что до сих пор так мало пакетов.
>>
> Ну, там сейчас все пакеты от mhz, -- если уже не так, -- извините. 

да, и лишь один пакет от alb@: xml-commons-resolver.

> Давайте подождем, что скажет Михаил.
> 

Хорошо, подождём  < "спеши медленно" (C) народная мудрость(?) :) >

Михаил тоже немного неуловим. Сказал недавно в devel@, что в hasher'е до 
сих пор какие-то проблемы ("странный выбор пакета JDK"), но я с таким 
пока не сталкивался.

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[devel] Re: Q: java development

[Mikhail Zabaluev]

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

Hello Vladimir,

On Fri, Sep 10, 2004 at 05:27:53PM +0400, Vladimir Lettiev wrote:
>
> Хорошо, подождём  < "спеши медленно" (C) народная мудрость(?) :) >
> 
> Михаил тоже немного неуловим. Сказал недавно в devel@, что в hasher'е до 
> сих пор какие-то проблемы ("странный выбор пакета JDK"), но я с таким 
> пока не сталкивался.

Проблемы были решены, пакеты выкладываются.

Про policy с jpackage.org: я его изучал и утянул много пакетов для
пересборки именно оттуда. Взял за основу, но некоторые вещи поменял.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
If God is perfect, why did He create discontinuous functions?

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

Re: [devel] Re: Q: java development

[Volkov Serge]

Hello Mikhail,

Saturday, September 11, 2004, 7:51:06 PM, you wrote:

MZ> Hello Vladimir,

MZ> On Fri, Sep 10, 2004 at 05:27:53PM +0400, Vladimir Lettiev wrote:
>>
>> Хорошо, подождём  < "спеши медленно" (C) народная мудрость(?) :) >
>> 
>> Михаил тоже немного неуловим. Сказал недавно в devel@, что в hasher'е до
>> сих пор какие-то проблемы ("странный выбор пакета JDK"), но я с таким
>> пока не сталкивался.

MZ> Проблемы были решены, пакеты выкладываются.

MZ> Про policy с jpackage.org: я его изучал и утянул много пакетов для
MZ> пересборки именно оттуда. Взял за основу, но некоторые вещи поменял.
Тогда хотелось бы узнать что было изменено и зачем?

Как бы ваше полиси в студию!



-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

Mikhail Zabaluev пишет:
> 
> Про policy с jpackage.org: я его изучал и утянул много пакетов для
> пересборки именно оттуда. Взял за основу, но некоторые вещи поменял.
> 

Надо опубликовать эту policy даже если она ещё полностью не оформлена. 
Очень важный момент это правила именования jar'ов (делать ли симлинки?), 
поскольку практически в каждом спеке в CLASSPATH должны явно указыватся 
пути к этим файлам.

У меня есть предложения по изменениям в пакетах java-common и 
j2se1.4-sun-doc. Как это лучше обсудить, через bugzilla, рассылку или в 
личной переписке?


-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[devel] Re: Q: java development

[Mikhail Zabaluev]

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

Hello Vladimir,

On Sat, Sep 11, 2004 at 11:47:06PM +0400, Vladimir Lettiev wrote:
>
> >Про policy с jpackage.org: я его изучал и утянул много пакетов для
> >пересборки именно оттуда. Взял за основу, но некоторые вещи поменял.
> >
> 
> Надо опубликовать эту policy даже если она ещё полностью не оформлена. 

В данный момент она существует главным образом в моей голове :)
Надо оформить в документ, конечно.

> Очень важный момент это правила именования jar'ов (делать ли симлинки?), 
> поскольку практически в каждом спеке в CLASSPATH должны явно указыватся 
> пути к этим файлам.

Я убрал симлинки на версии. Rationale: версии поддерживаются
rpm и выясняются с помощью его же, а для CLASSPATH они
не нужны и даже вредны.
То же с javadoc-каталогами: не удалось найти ни одной причины, почему
они должны иметь полные номера версий.

Из других изменений: все явно библиотечные (т.е. не используемые
напрямую через launcher'ы и проч.) пакеты отнесены в Development/Java,
иным группы даются по функциональной принадлежности.
У библиотечных пакетов не ставятся requires на j2se, другие
java-пакеты, за исключением очевидных жестко заданных случаев.
У пакетов c launcher'ами (напр. ant, tomcat), наоборот, ставятся
все requires, необходимые для работы.

> У меня есть предложения по изменениям в пакетах java-common и 
> j2se1.4-sun-doc. Как это лучше обсудить, через bugzilla, рассылку или в 
> личной переписке?

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

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Why do they call it baby-SITTING when all you do is run after them?

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

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

Mikhail Zabaluev пишет:
>>Надо опубликовать эту policy даже если она ещё полностью не оформлена. 
> 
> В данный момент она существует главным образом в моей голове :)
> Надо оформить в документ, конечно.
> 
Ok. Я подготавливаю свой draft, можно его будет обсудить.

Я не дождался вашего ответа и предпринял разведку боем: позавчера в 
Сизиф ушли 13 java-пакетов:
jakarta-commons-collections, jakarta-commons-daemon, 
jakarta-commons-daemon-jsvc, jakarta-commons-beanutils, 
jakarta-commons-pool, jakarta-commons-launcher, servletapi5, 
jakarta-commons-el, jakarta-commons-digester, jakarta-regexp, jmx, jndi, 
jakarta-commons-dbcp

Вообще их сборка для меня была нужна для того, чтобы как следует 
разобраться в процессе сборки java-пакетов. За их майнтейнерство я не 
держусь, поэтому отдам по первому обоснованному требованию. Пакеты 
выбраны по простому принципу: я просто иду по списку зависимостей tomcat5.
В сборке я придерживался стандартной полиси jpackage, т.е. туча 
симлинков, но зависимости выставлял только самые необходимые.

>>Очень важный момент это правила именования jar'ов (делать ли симлинки?), 
>>поскольку практически в каждом спеке в CLASSPATH должны явно указыватся 
>>пути к этим файлам.
> 
> Я убрал симлинки на версии. Rationale: версии поддерживаются
> rpm и выясняются с помощью его же, а для CLASSPATH они
> не нужны и даже вредны.
> То же с javadoc-каталогами: не удалось найти ни одной причины, почему
> они должны иметь полные номера версий.
> 
> Из других изменений: все явно библиотечные (т.е. не используемые
> напрямую через launcher'ы и проч.) пакеты отнесены в Development/Java,
> иным группы даются по функциональной принадлежности.
> У библиотечных пакетов не ставятся requires на j2se, другие
> java-пакеты, за исключением очевидных жестко заданных случаев.
> У пакетов c launcher'ами (напр. ant, tomcat), наоборот, ставятся
> все requires, необходимые для работы.
> 

Да, вы совершенно правы.
Только я бы ещё предложил создавать симлинк на то имя (*.jar), которое 
изначально задумано разработчиком. Например, jakarta-commons-logging.jar 
<-> commons-logging.jar. Поскольку во многих зависимых пакетах в 
build.xml/build.properties заложены именно такие имена jar'ов.

И ещё все java-пакеты должны зависеть от java-common.

>>У меня есть предложения по изменениям в пакетах java-common и 
>>j2se1.4-sun-doc. Как это лучше обсудить, через bugzilla, рассылку или в 
>>личной переписке?
> 
> В рассылку и Cc: мне -- я сейчас читаю рассылки в мерцающем режиме :(
> Если есть серьезные проблемы, требующие вмешательства, заносите в bugzilla.
> 

Предложения такие.
В пакете j2se1.4-sun-doc создавать симлинк или альтернативу (если вдруг 
ещё есть пакеты, которые провайдят доки):
/usr/share/javadoc/java -> /usr/share/doc/j2se-sun-1.4.2/api

Чтобы при сборке javadoc некоторых пакетов указывать именно такой путь 
(не зависящий от версии SDK), поскольку многие пакеты лезут в инет за 
этой документацией при сборке...

По пакету java-common. Нужно выделить в нём подпакет java-common-devel, 
куда внести хотя бы общие rpm-макросы:

%define _javadir %_datadir/java
%define _javadocdir %_datadir/javadoc
%define _j2sedocdir %_javadocdir/java
%define _javahome %_libdir/jdk

А также расширить кол-во функций. Например, нужна функция, аналог 
AddToClasspath, но не сама экспортирующая CLASSPATH, а просто 
возвращающая его в виде строки. В идеале бы функцию, которая сама 
экспортнёт всё что найдёт в %_javadir ;)

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re: [devel] Re: Q: java development

[Vitaly Lipatov]

On Thursday 16 September 2004 14:09, Vladimir Lettiev wrote:
> Mikhail Zabaluev пишет:
> >>Надо опубликовать эту policy даже если она ещё полностью не
> >> оформлена.
> >
> > В данный момент она существует главным образом в моей голове
> > :) Надо оформить в документ, конечно.
>
> Ok. Я подготавливаю свой draft, можно его будет обсудить.
>
> Я не дождался вашего ответа и предпринял разведку боем:
> позавчера в Сизиф ушли 13 java-пакетов:
> jakarta-commons-collections, jakarta-commons-daemon,
И всё-таки, почему не приняли префикс java- к Java-пакетам, как 
это было сделано для perl, python, ruby?

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

Vitaly Lipatov пишет:
>>Ok. Я подготавливаю свой draft, можно его будет обсудить.
>>
>>Я не дождался вашего ответа и предпринял разведку боем:
>>позавчера в Сизиф ушли 13 java-пакетов:
>>jakarta-commons-collections, jakarta-commons-daemon,
> 
> И всё-таки, почему не приняли префикс java- к Java-пакетам, как 
> это было сделано для perl, python, ruby?
> 

Трудно сказать, не видел ни в одном дистрибутиве такого подхода. Правда 
mandrake cooker складывает все такие пакеты в отдельный каталог, ни 
перл, ни руби, ни что иное не удостоилось такой чести. Наверное потому, 
что сам SDK проприетарный продукт и если что случиться, то можно быстро 
и просто rm -rf jpackage - и дистрибутив лицензионно чист. ;)

Да и вообще в идеале именовать пакеты на вроде package-0001.rpm и 
полностью перейти на  использование интелектуальных утилит для установки 
  и поиска нужной программы (не пакета!), а не полагаться на интуицию 
при виде какого-нибудь заковыристого названия.

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re: [devel] Re: Q: java development

[Vitaly Lipatov]

On Saturday 18 September 2004 22:15, Vladimir Lettiev wrote:
> Vitaly Lipatov пишет:
> >>Ok. Я подготавливаю свой draft, можно его будет обсудить.
> >>
> >>Я не дождался вашего ответа и предпринял разведку боем:
> >>позавчера в Сизиф ушли 13 java-пакетов:
> >>jakarta-commons-collections, jakarta-commons-daemon,
> >
> > И всё-таки, почему не приняли префикс java- к Java-пакетам,
> > как это было сделано для perl, python, ruby?
>
> Трудно сказать, не видел ни в одном дистрибутиве такого
Да при чём здесь другие дистрибутивы?
Вы же видели такой подход для perl и python? В чём отличие java?


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re[2]: [devel] Re: Q: java development

[Volkov Serge]

Hello Vitaly,

Saturday, September 18, 2004, 11:56:15 PM, you wrote:

VL> On Saturday 18 September 2004 22:15, Vladimir Lettiev wrote:
>> Vitaly Lipatov пишет:
>> >>Ok. Я подготавливаю свой draft, можно его будет обсудить.
>> >>
>> >>Я не дождался вашего ответа и предпринял разведку боем:
>> >>позавчера в Сизиф ушли 13 java-пакетов:
>> >>jakarta-commons-collections, jakarta-commons-daemon,
>> >
>> > И всё-таки, почему не приняли префикс java- к Java-пакетам,
>> > как это было сделано для perl, python, ruby?
>>
>> Трудно сказать, не видел ни в одном дистрибутиве такого
VL> Да при чём здесь другие дистрибутивы?
VL> Вы же видели такой подход для perl и python? В чём отличие java?

А зачем нам префикс java для пакета таких пакетов как jakarta этот
префикс сам по себе свидетельствует о принадлежности к java, а точнее
jakarta.

тоже самое касается и остальных пакетов, например зачем давать префикс
для программы OpenExchange если он использует java?

предлагаю префикс java закрепить только за библиотеками и утилитами
типа java-javamail, java-devel, java-common; для пакетов из проекта
Tomcat использовать префикс jakarta.




-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: Re[2]: [devel] Re: Q: java development

[Vitaly Lipatov]

On Sunday 19 September 2004 00:17, Volkov Serge wrote:
> VL> Вы же видели такой подход для perl и python? В чём отличие
> java?
>
> А зачем нам префикс java для пакета таких пакетов как jakarta
> этот префикс сам по себе свидетельствует о принадлежности к
> java, а точнее jakarta.
Хорошо, я не знал.

> тоже самое касается и остальных пакетов, например зачем давать
> префикс для программы OpenExchange если он использует java?
Конечно, только для библиотек.
>
> предлагаю префикс java закрепить только за библиотеками и
> утилитами типа java-javamail, java-devel, java-common; для
> пакетов из проекта Tomcat использовать префикс jakarta.
По-моему, неплохо.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

Vitaly Lipatov пишет:
>>>И всё-таки, почему не приняли префикс java- к Java-пакетам,
>>>как это было сделано для perl, python, ruby?
>>
>>Трудно сказать, не видел ни в одном дистрибутиве такого
> 
> Да при чём здесь другие дистрибутивы?
> Вы же видели такой подход для perl и python? В чём отличие java?
> 

Подход видел, отличия в этом плане у java нет. Все пакеты можно снабдить 
префиксом "java-".
Но...
* на java пишутся не только библиотеки, но и программы, указывать 
которым префикс java не имеет смысла (ну какая разница на чём написана 
прорамма?)
* большинство библиотек на java имеют в своём названии либо слово java 
(javamail, javamake...) или букву "j", что явно используется как 
сокращение от java (mx4j, jaf, jasper, ...) .
* проекты jakarta.apache.org исключительно java-ориентированные. Когда я 
говорю CPAN сразу возникает ассоциация perl. Тоже самое jakarta <-> java.

Добавить ко всему этому префикс "java-" значит сделать масло маслянное. 
А вот глубокого смысла и удобства в этом я не вижу. Ну если уж так 
хочется понять является ли пакет java (perl, python, ruby...) модулем, 
достаточно посмотреть его группу - это будет Development/Java(Perl, 
Python,Ruby..).


-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re[4]: [devel] Re: Q: java development

[Volkov Serge]

Hello Vitaly,

Sunday, September 19, 2004, 12:37:30 AM, you wrote:

VL> On Sunday 19 September 2004 00:17, Volkov Serge wrote:
>> VL> Вы же видели такой подход для perl и python? В чём отличие
>> java?
>>
>> А зачем нам префикс java для пакета таких пакетов как jakarta
>> этот префикс сам по себе свидетельствует о принадлежности к
>> java, а точнее jakarta.
VL> Хорошо, я не знал.

>> тоже самое касается и остальных пакетов, например зачем давать
>> префикс для программы OpenExchange если он использует java?
VL> Конечно, только для библиотек.
>>
>> предлагаю префикс java закрепить только за библиотеками и
>> утилитами типа java-javamail, java-devel, java-common; для
>> пакетов из проекта Tomcat использовать префикс jakarta.
VL> По-моему, неплохо.
Ну тогда надо оформлять policy и собирать пакеты, так как у меня
самого очень задачь зависит от java окружения.


-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

Volkov Serge пишет:
> предлагаю префикс java закрепить только за библиотеками и утилитами
> типа java-javamail, java-devel, java-common; для пакетов из проекта
> Tomcat использовать префикс jakarta.
> 

В принципе нормальный вариант.
На apache.org ещё много java-проектов (не только tomcat, jakarta*), 
например avalon (avalon.apache.org). IBM также активно учавствует... Как 
всё это обрабатывать?
Просто охватывая взглядом многочисленные java-проекты видишь, что трудно 
их под одну гребёнку... Есть проекты реализованные как на java, так и на 
C++, тут бесспорно требуется какое-то раздельное обозначение. Есть 
смешанные проекты (и C и java в исходниках). Стопроцентно придётся 
допускать какие-то исключения.
Может всё же не сильно прижимать java с этой унификацией?

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re[2]: [devel] Re: Q: java development

[Volkov Serge]

Hello Vladimir,

Sunday, September 19, 2004, 12:57:45 AM, you wrote:

VL> Volkov Serge пишет:
>> предлагаю префикс java закрепить только за библиотеками и утилитами
>> типа java-javamail, java-devel, java-common; для пакетов из проекта
>> Tomcat использовать префикс jakarta.
>> 

VL> В принципе нормальный вариант.
VL> На apache.org ещё много java-проектов (не только tomcat, jakarta*),
VL> например avalon (avalon.apache.org). IBM также активно учавствует... Как
VL> всё это обрабатывать?
VL> Просто охватывая взглядом многочисленные java-проекты видишь, что трудно
VL> их под одну гребёнку... Есть проекты реализованные как на java, так и на
VL> C++, тут бесспорно требуется какое-то раздельное обозначение. Есть
VL> смешанные проекты (и C и java в исходниках). Стопроцентно придётся
VL> допускать какие-то исключения.
VL> Может всё же не сильно прижимать java с этой унификацией?
Именно по этому я предложил префик java использовать для библиотек и
модулей.

Точно так же как в руби и перл perl-base и perl-String
Так и для java -> java-base (java-common) java-javamail
А те проекты, которые используют java просто будут его требовать в
зависимостях, а название у них будет зависиет от того, насколько этот
проект самостоятелен (обособлен от других) или явбялется или нет
библиотекой или инструментом для java?!

-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: [devel] Re: Q: java development

[Vitaly Lipatov]

On Sunday 19 September 2004 00:42, Vladimir Lettiev wrote:
> * на java пишутся не только библиотеки, но и программы,
> указывать которым префикс java не имеет смысла (ну какая
> разница на чём написана прорамма?)
да, не имеет смысла.
> * большинство библиотек на java имеют в своём названии либо
> слово java (javamail, javamake...) или букву "j", что явно
> используется как сокращение от java (mx4j, jaf, jasper, ...) .
А ant?
Знаете, PyQT тоже содержал в своём названии первые буквы от 
Python, но префикс для библиотек python-таки ввели, и мне 
кажется это разумным.

> * проекты jakarta.apache.org исключительно
> java-ориентированные. Когда я говорю CPAN сразу возникает
> ассоциация perl. Тоже самое jakarta <-> java.
договоримся о префиксе jakarta?

> Добавить ко всему этому префикс "java-" значит сделать масло
> маслянное. А вот глубокого смысла и удобства в этом я не вижу.
Что думают другие участники процесса?

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

Vitaly Lipatov пишет:
>>* большинство библиотек на java имеют в своём названии либо
>>слово java (javamail, javamake...) или букву "j", что явно
>>используется как сокращение от java (mx4j, jaf, jasper, ...) .
> 
> А ant?

ant - это не библиотека.

> Знаете, PyQT тоже содержал в своём названии первые буквы от 
> Python, но префикс для библиотек python-таки ввели, и мне 
> кажется это разумным.
>>* проекты jakarta.apache.org исключительно
>>java-ориентированные. Когда я говорю CPAN сразу возникает
>>ассоциация perl. Тоже самое jakarta <-> java.
> 
> договоримся о префиксе jakarta?
> 

Хорошо. Соотвественно для остальных библиотек обязателен префикс java.
Ну и последнее слово за Михаилом (mhz@).

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re: [devel] Re: Q: java development

[Vitaly Lipatov]

On Monday 20 September 2004 08:00, Vladimir Lettiev wrote:

> ant - это не библиотека.
Но и не программа?
build tool for Java
это не из серии того, что могло бы храниться в java-devel?

> Хорошо. Соотвественно для остальных библиотек обязателен
> префикс java. Ну и последнее слово за Михаилом (mhz@).
Конечно.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] Re: Q: java development

[Vladimir Lettiev]

Vitaly Lipatov wrote:
> On Monday 20 September 2004 08:00, Vladimir Lettiev wrote:
> 
> 
>>ant - это не библиотека.
> 
> Но и не программа?
> build tool for Java

ant - это программа, причём очень важная программа, аналог make, только 
для java.

> это не из серии того, что могло бы храниться в java-devel?
> 

Под java-devel вы понимаете виртуальный пакет, который вытягивает всю 
devel-среду для разработки java-приложений? Если так, то да.

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

[devel] Re: Q: java development

[Mikhail Zabaluev]

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

Hello Vladimir,

On Mon, Sep 20, 2004 at 08:00:31AM +0400, Vladimir Lettiev wrote:
>
> >Знаете, PyQT тоже содержал в своём названии первые буквы от 
> >Python, но префикс для библиотек python-таки ввели, и мне 
> >кажется это разумным.
> >>* проекты jakarta.apache.org исключительно
> >>java-ориентированные. Когда я говорю CPAN сразу возникает
> >>ассоциация perl. Тоже самое jakarta <-> java.
> >
> >договоримся о префиксе jakarta?
> >
> 
> Хорошо. Соотвественно для остальных библиотек обязателен префикс java.
> Ну и последнее слово за Михаилом (mhz@).

Последнее слово -- отказать.
Слишком много "масла масляного" (javamail, log4j) и не-библиотечных
пакетов; у части пакетов есть отличительный префикс "jakarta-".
К чему вообще этот педантизм с java-? Группы в RPM мало?  Может, еще
библиотеки C++ префиксом снабдим?

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
If a man has a strong faith he can indulge in the luxury of skepticism.
		-- Friedrich Nietzsche

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

Re: [devel] Re: Q: java development

[Volkov Serge]

Hello Mikhail,

Saturday, October 2, 2004, 2:24:38 AM, you wrote:

MZ> Hello Vladimir,

MZ> On Mon, Sep 20, 2004 at 08:00:31AM +0400, Vladimir Lettiev wrote:
>>
>> >Знаете, PyQT тоже содержал в своём названии первые буквы от 
>> >Python, но префикс для библиотек python-таки ввели, и мне 
>> >кажется это разумным.
>> >>* проекты jakarta.apache.org исключительно
>> >>java-ориентированные. Когда я говорю CPAN сразу возникает
>> >>ассоциация perl. Тоже самое jakarta <-> java.
>> >
>> >договоримся о префиксе jakarta?
>> >
>> 
>> Хорошо. Соотвественно для остальных библиотек обязателен префикс java.
>> Ну и последнее слово за Михаилом (mhz@).

MZ> Последнее слово -- отказать.
MZ> Слишком много "масла масляного" (javamail, log4j) и не-библиотечных
MZ> пакетов; у части пакетов есть отличительный префикс "jakarta-".
MZ> К чему вообще этот педантизм с java-? Группы в RPM мало?  Может, еще
MZ> библиотеки C++ префиксом снабдим?


Ну так и какое у нас в результате java policy ?

-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

[devel] Re: Q: java development

[Mikhail Zabaluev]

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

Hello,

On Sun, Oct 03, 2004 at 01:02:51AM +0400, Volkov Serge wrote:
>
> >> Хорошо. Соотвественно для остальных библиотек обязателен префикс java.
> >> Ну и последнее слово за Михаилом (mhz@).
> 
> MZ> Последнее слово -- отказать.
> MZ> Слишком много "масла масляного" (javamail, log4j) и не-библиотечных
> MZ> пакетов; у части пакетов есть отличительный префикс "jakarta-".
> MZ> К чему вообще этот педантизм с java-? Группы в RPM мало?  Может, еще
> MZ> библиотеки C++ префиксом снабдим?
> 
> 
> Ну так и какое у нас в результате java policy ?

Алан Кокс, кажется, говорил, что лучшее policy в том, чтобы не иметь policy :)
Мы все же не настолько круты, и некий начальный документ существует
стараниями Владимира Леттиева. В конце концов я до него доберусь,
и мы его опубликуем.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
God grant us the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.

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

[devel] [JT] Re: Q: java development

[Gleb Stiblo]

On Sat, Oct 02, 2004 at 02:24:38AM +0400, Mikhail Zabaluev wrote:
[...]
MZ> Последнее слово -- отказать.
MZ> Слишком много "масла масляного" (javamail, log4j) и не-библиотечных
MZ> пакетов; у части пакетов есть отличительный префикс "jakarta-".
MZ> К чему вообще этот педантизм с java-? Группы в RPM мало?  Может, еще
MZ> библиотеки C++ префиксом снабдим?
lib* ? Там правда не только C++ :).

-- 
Gleb Stiblo AKA UlfR 	<g.stiblo@sam-solutions.net>