https://www.altlinux.org/api.php?action=feedcontributions&user=195.160.222.83&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-28T09:34:48ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=Java/OracleSDK&diff=31186Java/OracleSDK2014-12-04T17:16:10Z<p>195.160.222.83: /* NOSRC In a Nutshell */</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
== Установка Oracle Java 6/7 SDK в ALTLinux ==<br />
<br />
<br />
__TOC__<br />
<br />
=== Лицензионные ограничения ===<br />
<br />
jdk-6u26-linux является последним фирменным JDK, распространяемым под лицензией<br />
[http://download.java.net/dlj/DLJ-v1.1.txt DLJ (Operating System Distributor License for Java version 1.1)].<br />
Эта лицензия явно разрешает распространять JDK в составе дистрибутива.<br />
Таким образом, java-1.6.0-sun-1.6.0.26 является последним JDK от Sun/Oracle, входящим в состав [[Sisyphus]].<br />
<br />
Последующие версии Oracle JDK теперь распространяются под лицензией Oracle Binary Code License,<br />
в которой есть явное разрешение распространять JDK вместе с java приложениями, например, в составе LiveCD,<br />
но нет явного разрешения распространять JDK в одиночку, как отдельный пакет.<br />
Поэтому их нет в сизифе.<br />
<br />
Однако ничто не мещает установить данные пакеты самостоятельно.<br />
Для безболезненной установки Oracle JDK под ALTLinux доступны .nosrc.rpm пакеты.<br />
В эти .nosrc.rpm пакеты собственно Oracle JDK не входит, его нужно отдельно скачать,<br />
после чего их можно пересобрать по инструкции ниже и получить обычные rpm пакеты,<br />
готовые к установке.<br />
<br />
=== NOSRC In a Nutshell ===<br />
<br />
Скачайте с <br />
http://fly.osdn.org.ua/~mike/packages/java/java-1.8.0-oracle/ (для Oracle JDK 8)<br />
с <br />
http://fly.osdn.org.ua/~mike/packages/java/java-1.7.0-oracle/ (для Oracle JDK 7)<br />
либо с <br />
http://fly.osdn.org.ua/~mike/packages/java/java-1.6.0-oracle/ (для Oracle JDK 6)<br />
соответствующий .nosrc.rpm пакет.<br />
Например, http://fly.osdn.org.ua/~mike/packages/java/java-1.7.0-oracle/java-1.7.0-oracle-1.7.0.21-alt1.nosrc.rpm<br />
<br />
Установите его командой вида <br />
rpm -i java-1.7.0-oracle-1.7.0.21-alt1.nosrc.rpm<br />
Скачайте в папку {{path|SOURCES/}} недостающий исходник для вашей архитектуры с <br />
сайта Oracle<br />
[http://www.oracle.com/technetwork/java/javase/downloads/index.html Java SE Downloads],<br />
[http://www.oracle.com/technetwork/java/javase/downloads/index.html download.oracle.com],<br />
если ссылки устареют, поищите новые в google.<br />
<br />
Например, для java-1.7.0-oracle-1.7.0.3 это будут файл<br />
<br />
(i586) http://download.oracle.com/otn-pub/java/jdk/7u3-b04/jdk-7u3-linux-i586.tar.gz<br />
<br />
(x86_64) http://download.oracle.com/otn-pub/java/jdk/7u3-b04/jdk-7u3-linux-x64.tar.gz<br />
<br />
Для java-1.7.0-oracle-1.7.0.21 это будут файлы {{pkg|jdk-7u21-linux-i586.tar.gz}} и {{pkg|jdk-7u21-linux-x64.tar.gz}}.<br />
<br />
Публикация nosrc.rpm может отставать от выпуска новых релизов java.<br />
Если случилось так, что на сайте Oracle доступна более свежая версия, <br />
чем имеющиеся nosrc.rpm, тогда можно просто обновить версию пакета в файле java-1.7.0-oracle.spec,<br />
затем собрать src.rpm по инструкции. Внизу дан пример правки spec файла.<br />
<source lang="diff"><br />
--- a/java-1.7.0-oracle.spec<br />
+++ b/java-1.7.0-oracle.spec<br />
@@ -38,7 +38,7 @@<br />
%define origin oracle<br />
%define priority 16040<br />
%define javaver %major.%minor<br />
-%define buildver 17<br />
+%define buildver 21<br />
<br />
%define jppname java-%{javaver}-%{origin}<br />
%define javaws_ver %{javaver}<br />
@@ -989,6 +989,9 @@ done<br />
<br />
<br />
%changelog<br />
+* Mon Apr 22 2013 Igor Vlasenko <viy@altlinux.ru> 0:1.7.0.21-alt1<br />
+- nosrc spec file for java sdk 7u21<br />
+<br />
* Fri Mar 08 2013 Igor Vlasenko <viy@altlinux.ru> 0:1.7.0.17-alt1<br />
- nosrc spec file for java sdk 7u17<br />
</source><br />
<br />
Установите в host-систему пакет rpm-build-java.<br />
Зайдите в папку {{path|SPECS/}}, поправьте при необходимости версию в spec-файле,<br />
и выполните команду (для Oracle JDK 7):<br />
rpmbuild -bs --nodeps java-1.7.0-oracle.spec<br />
Полученный в результате java-1.7.0-oracle-1.7.0.21-alt1.src.rpm [[Hasher/Краткое руководство|пересоберите в hasher]].<br />
<br />
Примечание: ключ --nodeps команды rpmbuild -bs позволяет выполнить ее без установки<br />
лишних зависимостей в хост-систему. При этом, если в хост-системе не будет некоторых дополнительных<br />
пакетов с макросами, именно, указанных в BuildRequires(pre): {{pkg|rpm-macros-alternatives browser-plugins-npapi-devel}},<br />
то rpmbuild будет выдавать предупреждения, связанные с отсутствием соответствующих макросов.<br />
На это можно не обращать внимания, если сборка src.rpm пакета состоялась.<br />
<br />
=== Переключение на Oracle JDK ===<br />
'''TODO:''' использование alternatives</div>195.160.222.83https://www.altlinux.org/index.php?title=Gear/cronbuild&diff=30176Gear/cronbuild2014-07-23T14:18:37Z<p>195.160.222.83: /* Другие файлы, используемые утилитой {{prg|gear-cronbuild-apply-hooks}} */</p>
<hr />
<div>{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}<br />
{{Category navigation|title=Автоматизация работы с пакетами|category=Packaging Automation}}<br />
[[Категория:Справочники]]<br />
<!-- {{stub}} --><br />
<br />
== Введение в cronbuild. ==<br />
<br />
Некоторые пакеты по своей природе нуждаются в постоянном обновлении,<br />
при этом при обновлении у этих пакетов спек практически не меняется.<br />
Например, к таким пакетам относятся различные базы - антивирусные, оборудования<br />
(foomatic-db, PCI IDs, мониторов, ...), cliparts, и т. д.<br />
Как правило, в версии/релизе таких пакетов присутствует timestamp.<br />
Система cronbuild предназначена для автоматизации сборки таких пакетов.<br />
<br />
Теперь майнтайнеру достаточно один раз настроить для пакета cronbuild<br />
и в дальнейшем при появлении обновлений пакет будет автоматически собираться в Сизиф<br />
до тех пор, пока сборка не сломается. Сервер cronbuild проверяет пакет на наличие обновлений <br />
с заданной майнтайнером периодичностью, по умолчанию это раз в неделю.<br />
<br />
При этом пакеты собираются только тогда, когда это действительно нужно:<br />
если после обновления файлы исходников не изменились (согласно git diff <commit before update>),<br />
то сборка пакета будет пропущена, так как в ней нет необходимости.<br />
<br />
Управлять сервисом Cronbuild просто: если нужно внести в пакет какие-то изменения, достаточно внести их локально и отправьть пакет на сборку вручную. При следующей попытке обновления робот склонирует уже измененный репозиторий, т.е. изменения будут подхвачены автоматически.<br />
<br />
== Настройка cronbuild. ==<br />
cronbuild состоит из 3-х частей:<br />
<br />
* локальные скрипты cronbuild для автоматизации обновления .git репозитрия.<br />
* утилиты для локальной сборки (пакет {{pkg|gear-cronbuild}})<br />
* сервер удаленной сборки (cronbuild repocop.altlinux.org)<br />
<br />
Для того, чтобы воспользоваться cronbuild, надо написать по примерам скрипт {{cmd|.gear/cronbuild-update-source}}<br />
и, возможно, другие скрипты, проверить их работоспособность с помощью локальных утилит и закоммитить их в .git.<br />
<br />
После этого gear-cronbuild можно пользоваться локально, для ускорения работы,<br />
а также можно разместить на сервере удаленной сборки.<br />
<br />
=== утилиты для локальной сборки (пакет {{pkg|gear-cronbuild}}) ===<br />
Для того, чтобы пользоваться скриптами cronbuild на локальной машине, необходимо установить пакет {{pkg|gear-cronbuild}}.<br />
Команда {{prg|gear-cronbuild-apply-hooks}} вызывает локальные скрипты cronbuild и обновляет git репозиторий до следующей версии.<br />
Для удобства пользователя есть скрипт-обертка {{prg|gear-cronbuild}},<br />
который обновляет репозиторий, собирает пакет, и в случае успеха, коммитит изменения.<br />
<br />
скрипт-обертка {{prg|gear-cronbuild}}:<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
gear-cronbuild-apply-hooks<br />
gear "$@"<br />
gear-commit<br />
</source><br />
<br />
=== локальные скрипты cronbuild для автоматизации обновления .git репозитрия ===<br />
<br />
Для работы cronbuild необходимо добавить в репозиторий .watch файл (см. [[Watch]].) <br />
либо написать скрипт {{cmd|.gear/cronbuild-update-source}}.<br />
Этот скрипт пишется индивидуально для каждого пакета. Его задача --<br />
обновить исходные тексты пакета, используя {{cmd|git-fetch}}, {{cmd|git-svn}}<br />
или просто {{cmd|wget}}. <br />
<br />
==== пример скрипта для обновления через wget ====<br />
Этот скрипт работает в случае, когда исходники публикуются в виде тарбола,<br />
а в git репозитарии хранятся в распакованном виде в поддиректории {{term|$PKGNAME}}.<br />
<br />
{{cmd|.gear/cronbuild-update-source}}:<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
PKGNAME="$(gear --command sh -- -c 'printf %s "$gear_pkg_name"')"<br />
rm -f $PKGNAME-SNAPSHOT.tar.gz<br />
wget -c http://www.pkgname.org/download/pkgname/pkgname-SNAPSHOT.tar.gz<br />
tar xzf $PKGNAME-SNAPSHOT.tar.gz<br />
rm -f $PKGNAME-SNAPSHOT.tar.gz<br />
git rm -r -f $PKGNAME<br />
rm -rf $PKGNAME<br />
mv $PKGNAME-SNAPSHOT $PKGNAME<br />
git add $PKGNAME<br />
</source><br />
==== обновление до новых версий с помошью .watch файла ====<br />
<br />
Если в репозитории присутствует .watch файл, то при отсутствии скрипта {{cmd|.gear/cronbuild-update-source}}<br />
утилита {{prg|gear-cronbuild-apply-hooks}} запустит связку утилит rpm-uscan + [[Gear/gear-uupdate|gear-uupdate]], см. [[Watch]].<br />
Если .watch файл корректный, и стркутура репозитария поддерживается утилитой gear-uupdate,<br />
то никаких скриптов для cronbuild создавать не нужно, .watch файла достаточно.<br />
<br />
==== замечания к скрипту ====<br />
* Если версия не изменилась/исходники не обновлялись, если вы ничего не добавляли в индекс git, просто выходите через exit 0. Иначе перед выходом сначала сбросьте изменения в индексе git с помощью {{cmd|git reset}}.<br />
* Удаляйте за собой мусор: временные файлы, каталоги и т.д.<br />
* скрипт должен сообщать о всех проблемах при обновлении через exit с ненулевым exit_code. Проще всего использовать {{path|#!/bin/sh -ve}},<br />
иначе придется у каждой команды проверять код завершения.<br />
* изменения должны быть добавлены в индекс git. <br />
* не нужно коммитить изменения: git-cronbuild это сделает автоматически после успешной сборки.<br />
<br />
==== Изменение версии/релиза пакета ====<br />
Утилита {{cmd|gear-cronbuild-update-spec-timestamp}}<br />
автоматически ищет и обновляет timestamp вида ГГГГММДД<br />
в тегах Serial, Epoch, Version, Release, либо в<br />
декларациях {{cmd|%define <macrosname> <timestamp>}}.<br />
Если пакет использует другую систему нумерации,<br />
необходимо создать свой скрипт изменения версии/релиза пакета<br />
{{path|.gear/cronbuild-update-version}}.<br />
Также можно переопределить стандартный changelog скриптом<br />
{{path|.gear/cronbuild-add-changelog}}.<br />
В теле этого скрипта должна быть вызвана команда {{cmd|add_changelog}}<br />
с желаемым текстом<ref>Для работы механизм обновления секции changelog нужно определить значение %packager в <code>~/.rpmmacros</code>.</ref>.<br />
<br />
=== сервер удаленной сборки (cronbuild repocop.altlinux.org) ===<br />
<br />
локальные утилиты gear-cronbuild имеют тот недостаток, что <br />
их надо не забывать запускать. Кроме того, они не автоматизируют отправку пакета в Сизиф.<br />
<br />
Сервер удаленной сборки cronbuild в песочнице repocop.altlinux.org<br />
позволяет автоматизировать сборку пакетов полностью.<br />
<br />
==== Как поставить пакет на сборку ====<br />
<br />
Если пакет успешно собирается с помощью gear-cronbuild локально,<br />
пришло время поставить его на автоматическую сборку.<br />
<br />
Для этого необходимо создать файл {{path|.gear/cronbuild-options}},<br />
указать там желаемую периодичность сборки и e-mail для рассылки оповещений,<br />
и зарегистрировать в bugzilla заявку на Infrastructure/cronbuild<br />
(пока это не реализовано, можно на пакет gear-cronbuild).<br />
<br />
==== Как вносить изменения в сборку ====<br />
<br />
сервер сборки поддерживает 2 системы транспорта:<br />
сборка по тегу из git+gear репозитория<br />
и сборка из srpm.<br />
<br />
* Сборка по тегу из git+gear репозитория.<br />
Управление сборкой устроенно очень просто:<br />
сервер клонирует последнюю успешную сборку в Сизиф<br />
и применяет к ней gear-cronbuild.<br />
Поэтому, если вы хотите починить или улучшить<br />
автоматическую сборку, просто соберите пакет вручную,<br />
и в дальнейшем автоматическая сборка будет идти на ее основе.<br />
<br />
* сборка из srpm.<br />
считается экспериментальной.<br />
<br />
== Приложения. ==<br />
=== Полный список служебных файлов cronbuild в {{path|.gear/}} ===<br />
<br />
==== Скрипты, используемые утилитой {{prg|gear-cronbuild-apply-hooks}} ====<br />
<br />
{| class="standard"<br />
!файл<br />
!Описание<br />
|-<br />
|class="shadow"|cronbuild-update-source<br />
|Основной скрипт для обновления содержимого пакета.<br />
|-<br />
|class="shadow"|cronbuild-update-version<br />
| Скрипт для обновления версии и/ли релиза пакета. Не обязателен.<br />
|-<br />
|class="shadow"|cronbuild-add-changelog<br />
| Скрипт для кастомизации changelog. Не обязателен.<br />
|}<br />
Скрипты должны быть помечены как исполняемые.<br />
<br />
Скрипты cronbuild-update-source, cronbuild-update-version, cronbuild-add-changelog получают спек-файл как первый аргумент.<br />
<br />
==== Другие файлы, используемые утилитой {{prg|gear-cronbuild-apply-hooks}} ====<br />
<br />
{| class="standard"<br />
!файл<br />
!Описание<br />
|-<br />
|class="shadow"|.gear/upstream/remotes<br />
|настройка [[Gear/remotes|remotes]] для клонированного git репозитория. Не обязателен.<br />
|-<br />
|class="shadow"|.gear/cronbuild-git-config<br />
|опции к команде git-config, для дополнительной настройки клонированного git репозитория. Устарел.<br />
|}<br />
<br />
==== Файлы, используемые сервером сборки cronbuild repocop.altlinux.org ====<br />
<br />
{| class="standard"<br />
!файл<br />
!Описание<br />
|-<br />
|class="shadow"|cronbuild-tagname<br />
| Скрипт для кастомизации git tag name. Не обязателен.<br />
|-<br />
|class="shadow"|cronbuild-tagmsg<br />
| Скрипт для кастомизации git tag message. Не обязателен.<br />
|-<br />
|class="shadow"|cronbuild-options<br />
| Конфигурационный файл. Требуется при размещении на сервере cronbuild.<br />
|}<br />
Скрипты должны быть помечены как исполняемые.<br />
К файлам конфигурации это не относится.<br />
<br />
=== cronbuild-options ===<br />
{| class="standard"<br />
!переменная<br />
!Описание<br />
|-<br />
|class="shadow"|cronbuild_requires<br />
|набор дополнительных пакетов, который будет передан в hsh-install для установки в chroot.<br />
необходим, если скрипты используют утилиты, не входящие в базовый набор (curl, wget, git, unzip, ...)<br />
|-<br />
|class="shadow"|cronbuild_interval<br />
|периодичность сборок в днях. желательно.<br />
|-<br />
|class="shadow"|cronbuild_mailto<br />
|e-mail ответственного. обязательно.<br />
|-<br />
|class="shadow"|cronbuild_cc<br />
|список дополнительных e-mail (optional)<br />
|-<br />
|class="shadow"|cronbuild_mastergit<br />
|experimental<br />
|-<br />
|class="shadow"|cronbuild_masterbranch<br />
|experimental<br />
|}<br />
<br />
=== Пример использования .gear/cronbuild-* ===<br />
<br />
== Примечания ==<br />
<references /><br />
<br />
{| class="wide"<br />
| Разработано при поддержке [http://www.fasie.ru/ Фонда содействия развитию МП НТС] в рамках НИОКР 01201066526<br />
| [[Изображение:Logo_FASIE_preview.jpg|200px|rigft]]<br />
|}</div>195.160.222.83https://www.altlinux.org/index.php?title=NFS&diff=19213NFS2011-06-28T13:10:01Z<p>195.160.222.83: /* Запуск NFS */</p>
<hr />
<div>[[Категория:Admin]]<br />
{{stub}}<br />
<br />
== NFS ==<br />
Важной особенностью NFS является то, что она рассчитана на использование внутри безопасной сети, рабочим станциям в которой можно доверять, поскольку авторизация доступа к файлам, смонтированным на NFS осуществляется на основании идентификатора пользователя, а подлинность пользователя каждая машина в сети проверяет самостоятельно.<br />
Вытекающим отсюда требованием является то, что пользователь должен быть зарегистрирован и на клиенте и на сервере NFS и иметь там одно и то же входное имя (login) и идентификатор. Это достигается использованием централизованной аутентификации (например, с помощью PAM и сервера аутентификации или NIS).<br />
<br />
Для запуска nfs требуется, чтобы в системе были установлены следующие пакеты:<br />
* nfs-server или unfs3 (в OpenVZ VE ядерный NFS-сервер не работает)<br />
* portmap (в шестой платформе заменен на rpcbind) <br />
* nfs-clients (содержит в себе nfslock)<br />
(в некоторых системах вместо nfs-server и nfs-clients имеется пакет nfs-utils)<br />
<br />
=== Настройка portmap ===<br />
Для работы nfs необходим сервис {{pkg|portmap}}. По умолчанию, сервис {{pkg|portmap}}<br />
запущен только на loopback (lo) интерфейсе в целях безопасности.<br />
Этого достаточно для раздачи сетевых ресурсов через nfs4.<br />
<br />
Однако при этом не будет работать монтирование каталогов по nfs3.<br />
Если это действительно нужно, то <br />
нехотя коментируем в файле /etc/sysconfig/portmap строку PORTMAP_ARGS="-l",<br />
прописываем в {{path|/etc/hosts.allow}} сеть, в которую раздаем:<br />
portmap mountd nfsd statd lockd rquotad : 192.168.ххх.0/255.255.255.0<br />
и в {{path|/etc/hosts.deny}}:<br />
portmap mountd nfsd statd lockd rquotad : ALL<br />
после этого еще раз вдумчиво читаем<br />
[http://tldp.org/HOWTO/NFS-HOWTO/security.html http://tldp.org/HOWTO/NFS-HOWTO/security.html].<br />
и глубоко размышляем над глубокой небезопасностью запуска portmap без PORTMAP_ARGS="-l"<br />
и использования nfs3.<br />
<br />
=== Настройка rpcbind, для шестой платформы===<br />
Начиная с шестой платформы portmap заменен на rpcbind. Настраивается аналогично portmap. Конфигурационный файл /etc/sysconfig/rpcbind, для использования nfs 3, закомментировать:<br />
<br />
control rpcbind server<br />
<br />
=== Настройка kerberos ===<br />
<br />
Для rw каталогов жедательно настроить kerberos.<br />
<br />
TODO<br />
<br />
Для read-only можно просто закоментировать в файле /etc/sysconfig/nfs строку<br />
SECURE_NFS=yes<br />
<br />
=== Настройка сервера NFS ===<br />
<br />
1. В файле /etc/exports указываются каталоги, которые мы экспортируем (разрешаем монтировать с других машин) (см. man exports).<br />
<br />
По соображениям безопасности не рекомендуется экспортировать каталоги по протоколу NFS 3.<br />
Рекомендуется использовать NFS 4.<br />
<br />
==== синтаксис для экспорта через NFS 3 ====<br />
<br />
<pre>/mysharedir ipaddr1(rw) ipaddr2(ro)</pre><br />
Например<br />
<pre>/mysharedir 192.168.0.1/24(rw)</pre><br />
<br />
В скобочках указываются дополнительные параметры:<br />
: rw — разрешены чтение и запись<br />
: ro — разрешено только чтение<br />
: no_root_squash — отключение ограничения прав root<br />
<br />
По умолчанию пользователь root имеет на смонтированных ресурсах права пользователя nobody.<br />
<br />
Можно указывать разрешение экспорта сразу для подсети.<br />
Например разрешение для машин из подсети 192.168.0.X строка будет выглядеть так:<br />
<pre>/mysharedir 192.168.0.1/24(rw)</pre><br />
<br />
Подробную информацию о формате файла можно посмотреть командой <tt>man exports</tt><br />
<br />
==== синтаксис для экспорта через NFS 4 ====<br />
экспортируемые по NFS 4 каталоги имеют тот же синтаксис, что и через NFS3,<br />
за исключением того, что все они должны быть в одном подкаталоге (chroot для безопасности).<br />
Пусть это каталог /exports. Тогда необходимо подмонтировать остальные экспортированные каталоги <br />
внутрь /exports с помощью mount --bind ({{cmd|mount --bind /mysharedir /exports/mysharedir}}), прописать в fstab:<br />
/mysharedir /exports/mysharedir none bind 0 0<br />
и прописать в /etc/exports:<br />
отличие с NFS3 в том, что нужно будет добавить nohide к mysharedir и явно <br />
обьявить корневой каталог экспорта с fsid=0.<br />
/exports 192.168.0.1/24(fsid=0,ro,insecure,all_squash)<br />
/exports/mysharedir 192.168.0.1/24(nohide,ro,insecure,all_squash)<br />
<br />
=== Запуск NFS ===<br />
<br />
1. После настройки файла необходимо запустить сервис rpcbind (для p6,portmap для p5) командой:<br />
<pre>(p5)# service portmap start</pre><br />
<pre>(p6)# service rpcbind start</pre><br />
<br />
2. Запустить непосредственно nfs-server командой:<br />
<pre># service nfs start</pre><br />
<br />
3. Запустить сервис блокировок командой:<br />
<pre># service nfslock start</pre><br />
<br />
Если все команды прошли успешно и не выдавали ошибок, то сервер можно считать работающим.<br />
Дополнительно можно запустить команду <tt>exportfs</tt>, которая выведет текущие настройки на данный момент.<br />
В случае нормальной работы она должна вывести на экран записи из файла /etc/exports<br />
<br />
Для запуска сервисов при старте системы:<br />
<pre>chkconfig rpcbind on (chkconfig portmap on)<br />
chkconfig nfs on<br />
chkconfig nfslock on</pre><br />
<br />
=== Использование NFS ===<br />
Подключение к nfs-серверу можно производить вручную, а можно настроить автоматическое подключение при загрузке.<br />
<br />
Допустим машина где запущен nfs-server называется server, и нам необходимо смонтировать с сервера каталог /myshare<br />
Тогда, для ручного способа достаточно (из под пользователя root) выполнить команду:<br />
<pre>mount -t nfs4 -o proto=tcp,port=2049 server:/myshare /mnt/myshare</pre><br />
или (NFS3)<br />
<pre>mount -t nfs server:/myshare /mnt/myshare</pre><br />
<br />
где,<br />
/mnt/myshare — локальный каталог куда монтируется удалённый каталог.<br />
<br />
Для автоматического монтирования к nfs-серверу при загрузке необходимо добавить следующую строку в файл <tt>/etc/fstab</tt>:<br />
<pre>server:/myshare /mnt/myshare nfs4 proto=tcp,port=2049,intr,soft,lock,_netdev</pre><br />
или (NFS3)<br />
<pre>server:/myshare /mnt/myshare nfs intr,soft,lock,_netdev</pre><br />
<br />
где,<br />
intr — позволяет прервать процесс при необходимости<br />
soft — предотвращает от зависания в случае недоступности удалённой машины.<br />
<br />
Прежде чем изменять /etc/fstab, попробуйте смонтировать вручную и убедитесь, что всё работает.<br />
<br />
==== Автомонтирование ====<br />
Осуществляется при помощи automount, autofs или subfs. Рецепт mike@ для subfs (фрагмент /etc/fstab), NFS4<br />
<pre>server:/var/ftp/pub /pub subfs fs=nfs4,program=/sbin/net-submountd,interval=5,proto=tcp,port=2049,soft,_netdev 0 0</pre><br />
или NFS3<br />
<pre>server:/var/ftp/pub /pub subfs fs=nfs,program=/sbin/net-submountd,interval=5,soft,_netdev 0 0</pre><br />
<br />
=== Ссылки ===<br />
<br />
* [http://wiki.sisyphus.ru/net/nfs http://wiki.sisyphus.ru/net/nfs]<br />
* [http://www.botik.ru/rented/rldp/www/ldp/nag-20/mountd.htm http://www.botik.ru/rented/rldp/www/ldp/nag-20/mountd.htm]<br />
* [http://nfs.sourceforge.net/ http://nfs.sourceforge.net/]<br />
* [http://www.intuit.ru/department/os/adminsolaris/8/ http://www.intuit.ru/department/os/adminsolaris/8/]<br />
* [http://sky.inp.nsk.su/~bolkhov/teach/inpunix/setup_nfs.ru.html http://sky.inp.nsk.su/~bolkhov/teach/inpunix/setup_nfs.ru.html]<br />
* [http://skif.bas-net.by/bsuir/base/node87.html http://skif.bas-net.by/bsuir/base/node87.html]<br />
* [http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/network-nfs.html http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/network-nfs.html]<br />
* [http://ivantechblog.blogspot.com/2010/01/nfs-altlinux-50.html http://ivantechblog.blogspot.com/2010/01/nfs-altlinux-50.html]</div>195.160.222.83https://www.altlinux.org/index.php?title=Gear/cronbuild&diff=16562Gear/cronbuild2010-10-15T21:49:40Z<p>195.160.222.83: </p>
<hr />
<div>{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}<br />
<!-- {{stub}} --><br />
<br />
== Введение в cronbuild. ==<br />
<br />
Некоторые пакеты по своей природе нуждаются в постоянном обновлении,<br />
при этом при обновлении у этих пакетов спек практически не меняется.<br />
К таким пакетам относятся различные базы - антивирусные, оборудования<br />
(foomatic-db, PCI IDs, мониторов, ...), cliparts, и т. д.<br />
Как правило, в версии/релизе таких пакетов присутствует timestamp.<br />
Система cronbuild предназначена для автоматизации сборки таких пакетов.<br />
Теперь майнтайнеру достаточно один раз настроить для пакета cronbuild<br />
и пакет будет автоматически собираться в Сизиф с заданной майнтайнером периодичностью,<br />
например, раз в неделю, до тех пор, пока сборка не сломается.<br />
<br />
При этом пакеты собираются только тогда, когда это действительно нужно:<br />
если после обновления файлы исходников не изменились (согласно git diff <commit before update>),<br />
то сборка пакета будет пропущена, так как в ней нет необходимости.<br />
<br />
Управлять роботом очень легко: если нужно внести в пакет какие-то изменения,<br />
просто внесите их локально и отправьте пакет на сборку вручную.<br />
Робот автоматически подхватит вашу работу.<br />
<br />
== Настройка cronbuild. ==<br />
cronbuild состоит из 3-х частей:<br />
<br />
* локальные скрипты cronbuild для автоматизации обновления .git репозитрия.<br />
* утилиты для локальной сборки (пакет {{pkg|gear-cronbuild}})<br />
* сервер удаленной сборки (cronbuild repocop.altlinux.org)<br />
<br />
Для того, чтобы воспользоваться cronbuild, надо написать по примерам скрипт {{cmd|.gear/cronbuild-update-source}}<br />
и, возможно, другие скрипты, проверить их работоспособность с помощью локальных утилит и закоммитить их в .git.<br />
<br />
После этого gear-cronbuild можно пользоваться локально, для ускорения работы,<br />
а можно подключть в сервер удаленной сборки.<br />
<br />
=== утилиты для локальной сборки (пакет {{pkg|gear-cronbuild}}) ===<br />
Для того, чтобы пользоваться скриптами cronbuild на локальной машине, необходимо установить пакет {{pkg|gear-cronbuild}}.<br />
Команда {{prg|gear-cronbuild-apply-hooks}} вызывает локальные скрипты cronbuild и обновляет git репозиторий до следующей версии.<br />
Для удобства пользователя есть скрипт-обертка {{prg|gear-cronbuild}},<br />
который обновляет репозиторий, собирает пакет, и в случае успеха, коммитит изменения.<br />
<br />
скрипт-обертка {{prg|gear-cronbuild}}:<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
gear-cronbuild-apply-hooks<br />
gear "$@"<br />
gear-commit<br />
</source><br />
<br />
=== локальные скрипты cronbuild для автоматизации обновления .git репозитрия ===<br />
<br />
Сердцем cronbuild является скрипт {{cmd|.gear/cronbuild-update-source}}.<br />
Этот скрипт пишется индивидуально для каждого пакета. Его задача --<br />
обновить исходные тексты пакета, используя {{cmd|git-fetch}}, {{cmd|git-svn}}<br />
или просто {{cmd|wget}}. <br />
<br />
==== пример скрипта для обновления через wget ====<br />
Этот скрипт работает в случае, когда исходники публикуются в виде тарбола,<br />
а в git репозитарии хранятся в распакованном виде в поддиректории {{term|$PKGNAME}}.<br />
<br />
{{cmd|.gear/cronbuild-update-source}}:<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
PKGNAME="$(gear --command sh -- -c 'printf %s "$gear_pkg_name"')"<br />
rm -f $PKGNAME-SNAPSHOT.tar.gz<br />
wget -c http://www.pkgname.org/download/pkgname/pkgname-SNAPSHOT.tar.gz<br />
tar xzf $PKGNAME-SNAPSHOT.tar.gz<br />
rm -f $PKGNAME-SNAPSHOT.tar.gz<br />
git rm -r -f $PKGNAME<br />
rm -rf $PKGNAME<br />
mv $PKGNAME-SNAPSHOT $PKGNAME<br />
git add $PKGNAME<br />
</source><br />
==== пример скрипта для обновления при выходе новых версий с помошью .watch файла ====<br />
<br />
Этот скрипт работает в случае, когда исходники публикуются в виде тарбола,<br />
а в git репозитарии хранятся в распакованном виде в поддиректории {{term|$PKGNAME}}.<br />
выход новых версий проверяется с помощью .watch файла.<br />
<br />
{{cmd|.gear/cronbuild-update-source}}:<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
PKGNAME="$(gear --command sh -- -c 'printf %s "$gear_pkg_name"')"<br />
url=`uscan -f $PKGNAME.watch`<br />
file=`basename "$url"`<br />
version=${file##$PKGNAME-}<br />
version=${version%%\.tar.*}<br />
echo $file $version<br />
gear_pkg_version="$(gear --command sh -- -c 'printf %s "$gear_pkg_version"')"<br />
[ "x$version" = "x$gear_pkg_version" ] && exit 0;<br />
rm -f $PKGNAME-*.tar.*<br />
wget -c $url<br />
tar xf $file<br />
rm -f $file<br />
git rm -r -f $PKGNAME<br />
rm -rf $PKGNAME<br />
mv $PKGNAME-*/ $PKGNAME<br />
git add $PKGNAME<br />
gear_specfile="$(gear --command sh -- -c 'printf %s "$gear_specfile"')"<br />
sed -i "s|^\(Version:).*|\1 $version|" $gear_specfile<br />
</source><br />
Заметим, что в скрипте также обновлялась версия,<br />
поэтому нужно создать пустой исполняемый файл <br />
{{cmd|.gear/cronbuild-update-version}}<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
</source><br />
чтобы переопределить стандартный метод.<br />
<br />
==== замечания к скрипту ====<br />
* скрипт должен сообщать о всех проблемах при обновлении. Проще всего использовать {{path|#!/bin/sh -ve}},<br />
иначе придется у каждой команды проверять код завершения.<br />
* изменения должны быть добавлены в индекс git. <br />
* не нужно коммитить изменения: git-cronbuild это сделает автоматически после успешной сборки.<br />
<br />
==== Изменение версии/релиза пакета ====<br />
Утилита {{cmd|gear-cronbuild-update-spec-timestamp}}<br />
автоматически ищет и обновляет timestamp вида ГГГГММДД<br />
в тегах Serial, Epoch, Version, Release, либо в<br />
декларациях {{cmd|%define <macrosname> <timestamp>}}.<br />
Если пакет использует другую систему нумерации,<br />
необходимо создать свой скрипт изменения версии/релиза пакета<br />
{{path|.gear/cronbuild-update-version}}.<br />
Также можно переопределить стандартный changelog скриптом<br />
{{path|.gear/cronbuild-add-changelog}}.<br />
В теле этого скрипта должна быть вызвана команда {{cmd|add_changelog}}<br />
с желаемым текстом.<br />
<br />
=== сервер удаленной сборки (cronbuild repocop.altlinux.org) ===<br />
<br />
локальные утилиты gear-cronbuild имеют тот недостаток, что <br />
их надо не забывать запускать. Кроме того, они не автоматизируют отправку пакета в Сизиф.<br />
<br />
Сервер удаленной сборки cronbuild в песочнице repocop.altlinux.org<br />
позволяет автоматизировать сборку пакетов полностью.<br />
<br />
==== Как поставить пакет на сборку ====<br />
<br />
Если пакет успешно собирается с помощью gear-cronbuild локально,<br />
пришло время поставить его на автоматическую сборку.<br />
<br />
Для этого необходимо создать файл {{path|.gear/cronbuild-options}},<br />
указать там желаемую периодичность сборки и e-mail для рассылки оповещений,<br />
и зарегистрировать в bugzilla заявку на Infrastructure/cronbuild<br />
(пока это не реализовано, можно на пакет gear-cronbuild).<br />
<br />
==== Как вносить изменения в сборку ====<br />
<br />
сервер сборки поддерживает 2 системы транспорта:<br />
сборка по тегу из git+gear репозитория<br />
и сборка из srpm.<br />
<br />
* Сборка по тегу из git+gear репозитория.<br />
Управление сборкой устроенно очень просто:<br />
сервер клонирует последнюю успешную сборку в Сизиф<br />
и применяет к ней gear-cronbuild.<br />
Поэтому, если вы хотите починить или улучшить<br />
автоматическую сборку, просто соберите пакет вручную,<br />
и в дальнейшем автоматическая сборка будет идти на ее основе.<br />
<br />
* сборка из srpm.<br />
считается экспериментальной.<br />
<br />
== Приложения. ==<br />
=== Полный список служебных файлов cronbuild в {{path|.gear/}} ===<br />
{| class="standard"<br />
!файл<br />
!Описание<br />
|-<br />
|class="shadow"|cronbuild-update-source<br />
|Основной скрипт для обновления содержимого пакета.<br />
|-<br />
|class="shadow"|cronbuild-update-version<br />
| Скрипт для обновления версии и/ли релиза пакета. Не обязателен.<br />
|-<br />
|class="shadow"|cronbuild-add-changelog<br />
| Скрипт для кастомизации changelog. Не обязателен.<br />
|-<br />
|class="shadow"|cronbuild-options<br />
| Конфигурационный файл. Не обязателен.<br />
|}<br />
Скрипты должны быть помечены как исполняемые.<br />
К файлам конфигурации это не относится.<br />
<br />
Скрипты получают спек-файл как первый аргумент.<br />
<br />
=== cronbuild-options ===<br />
{| class="standard"<br />
!переменная<br />
!Описание<br />
|-<br />
|class="shadow"|cronbuild_requires<br />
|набор дополнительных пакетов, который будет передан в hsh-install для установки в chroot.<br />
необходим, если скрипты используют утилиты, не входящие в базовый набор (curl, wget, git, unzip, ...)<br />
|-<br />
|class="shadow"|cronbuild_interval<br />
|периодичность сборок в днях. желательно.<br />
|-<br />
|class="shadow"|cronbuild_mailto<br />
|e-mail ответственного. обязательно.<br />
|-<br />
|class="shadow"|cronbuild_cc<br />
|список дополнительных e-mail (optional)<br />
|-<br />
|class="shadow"|cronbuild_mastergit<br />
|experimental<br />
|-<br />
|class="shadow"|cronbuild_masterbranch<br />
|experimental<br />
|}<br />
<br />
=== Пример использования .gear/cronbuild-* ===</div>195.160.222.83https://www.altlinux.org/index.php?title=Java_Policy&diff=16474Java Policy2010-09-28T16:10:46Z<p>195.160.222.83: /* Необходимо обеспечивать максимальную запускаемость на разных JVM */</p>
<hr />
<div>{{Policy<br />
|responsible=Игорь Власенко<br />
|since_branch=5.0}}<br />
<br />
'''ALT Linux Java Policy: Требования к сборке java-приложений'''<br />
<br />
== Сфера применения ==<br />
<br />
Данное полиси описывает требования к сборке и упаковке java-приложений и java-библиотек в Сизифе,<br />
и является расширением и толкованием JPackage Policy применительно к ALT Linux.<br />
<br />
== Необходимо соблюдать JPackage Policy ==<br />
<br />
Основное условие упаковки java-библиотек и приложений:<br />
При упаковке приложений для сизифа '''необходимо''' соблюдать JPackage Policy.<br />
<br />
Оригинал JPackagePolicy можно найти в пакете jpackage-utils (в Сизифе или на [http://www.jpackage.org/ www.jpackage.org]).<br />
Есть [[Java/JPackagePolicyTranslation|перевод JPackagePolicy на русский.]]<br />
<br />
== Необходимо обеспечивать максимальную запускаемость на разных JVM ==<br />
<br />
В настоящее время в Сизифе поддерживаются JVM<br />
: java6 (java-1.6.0-sun, java-1.6.0-openjdk),<br />
<br />
Также присутствуют частично поддерживаемые JVM<br />
: java5 (java-1.5.0-sun, java-1.5.0-gcj43).<br />
и неподдерживаемые JVM<br />
: java4 (java-1.4.2-sun, java-1.4.2-blackdown, java-1.4.2-gcj41).<br />
<br />
Компиляторы старших версий java по умолчанию создают class-файлы, несовместимые с младшими версиями java.<br />
Например, class-файл, собранный под java6 по умолчанию, не будет работать под java5 и ниже.<br />
Более того, если код приложения собран под java5, но хотя бы одна из используемых им библиотек собрана под<br />
java6, то и все приложение не сможет работать под java5 и ниже (class version poisoning).<br />
<br />
Пользовательские приложения '''должны запускаться и работать под всеми поддерживаемыми JVM''' (java5, java6).<br />
Поэтому '''необходимо''' следить, чтобы в сборочных скриптах для maven, ant или make компилятор вызывался<br />
с параметрами '''source и target в значении 1.5 или меньше''', если код не требует иного, либо использовать<br />
BuildRequires: java-devel-default<br />
Эта зависимость заведомо поставит в сборочную среду компилятор, который генерирует код, работающий на всех поддерживаемых JVM.<br />
<br />
Исключением являются приложения, явно использующие особенности диалекта java6 и требующие для сборки java6 и выше. Однако и<br />
для них рекомендуется явно указывать source и target в значении 1.6, поскольку со временем в сизифе появится java7.<br />
<br />
Для библиотек дополнительно рекомендуется source и target в значении 1.4 или меньше, поскольку java4 JVM еще присутствуют<br />
в сизифе, если их код это поддерживает.<br />
<br />
== Необходимо избегать зависимостей на конкретную JVM ==<br />
<br />
=== Установочные зависимости ===<br />
Программы '''не должны''' иметь явные зависимости Requires: java-X.Y.Z-vendor — это '''ЗЛО'''.<br />
<br />
В пакете единственно допустимы зависимости вида<br />
Requires: java<br />
Замечание. для указания минимальной версии JVM, под которой может работать программа,<br />
следует использовать конструкцию<br />
Requires: java >= 1.x.y<br />
например,<br />
Requires: java >= 1.6.0<br />
Если программа работает под текущую минимальную поддерживаемую JVM<br />
(сейчас у нас наименьшая JVM — это java-1.5.0),<br />
то '''рекомендуется''' писать просто Requires: java без версии.<br />
<br />
В старых пакетах вместо Requires: java может встретиться Requires: j2se.<br />
Эти provides устарели, поэтому все такие вхождения следует заменить на<br />
Requires: java.<br />
<br />
Для чистых библиотек, не являющихся одновременно приложениями, рекомендуется<br />
вообще избегать каких-либо зависимостей на java. (Они им и не нужны).<br />
<br />
=== Сборочные зависимости ===<br />
Программы '''не должны''' иметь явные зависимости BuildRequires: java-X.Y.Z-vendor-devel — это ЗЛО.<br />
<br />
Рекомендуется всегда собирать программы компилятором наименьшей подходящей версии<br />
(см. выше, /Необходимо обеспечивать максимальную запускаемость на разных JVM/).<br />
Однако если программа будет иметь явную зависимость на такой компилятор,<br />
то когда компилятор уйдет в obsolete, программа перестанет собираться.<br />
Поэтому зависимость на компилятор java (в пакетах java*-devel)<br />
должна быть виртуальной.<br />
<br />
Официально рекомендуемая зависимость — это<br />
BuildRequires: java-devel-default<br />
В настоящее время это вызовет установку java-devel = 1.5.0.<br />
<br />
В крайне редких случаях исходные тексты программы могут иметь особенности<br />
диалекта java6. Только в этом случае допускается указывать версионированную<br />
зависимость на компилятор версии не ниже 6:<br />
BuildRequires: java-devel >= 1.6.0<br />
<br />
== Пакеты из репозиториев jpackage.org желательно сопровождать роботом ==<br />
<br />
'''Не желательно''' собирать в Сизиф java-пакеты из репозиториев jpackage.org а также fedora.org вручную.<br />
Для этого есть робот сопровождения. Его можно взять в git, viy/packages/jppimport.git.<br />
<br />
Если пакет из репозиториев jpackage.org сопровождается вручную, он обязан быть совместимым с<br />
пакетом из jpackage по альтернативам, Provides и названиям упакованных jar.<br />
<br />
== Использование сторонних бинарных сборок крайне не рекомендуется ==<br />
Крайне не рекомендуется использование бинарных кодов, взятых откуда либо кроме Сизифа.<br />
* Пакеты должны собираться из исходных текстов, если это позволяет лицензия.<br />
Если пакет не собран из исходных текстов, а инсталлирует готовый jar, несмотря на присутствие исходных текстов,<br />
то лучше его в Сизиф не класть (но можно положить в Дедал в ожидании доработки).<br />
* Пакеты не должны использовать при сборке чужие библиотеки.<br />
Очень часто вместе с исходными текстами идут готовые собранные сторонние библиотеки.<br />
Пакеты не должны использовать при сборке эти готовые сторонние собранные библиотеки,<br />
а должны использовать вместо них библиотеки, собранные в Сизифе.<br />
Если какой-то готовой сторонней собранной библиотеки в Сизифе нет, ее необходимо сначала туда собрать.<br />
<br />
== Другие ограничения ==<br />
<br />
=== В MANIFEST.MF не должно быть атрибута Class-Path ===<br />
см. [[Java/ClassPathInManifest]]<br />
<br />
=== Устаревшие макросы ===<br />
<br />
Макросы <tt>%ant_build</tt>, <tt>%set_classpath</tt>, <tt>%add_classpath</tt> объявлены устаревшими.<br />
В пакетах конструкции вида<br />
%set_classpath /usr/share/java/foo.jar<br />
%add_classpath /usr/share/java/bar.jar<br />
нужно заменить на<br />
export CLASSPATH=$(build-classpath foo bar)<br />
а <tt>%ant_build</tt> — на %ant</tt>.<br />
<br />
== Дополнительные требования к сборке библиотек ==<br />
<br />
=== требуется упаковывать pom файлы ===<br />
<br />
Если для библиотеки существует pom файл, в самом ли проекте, либо в центральном maven2 репозитории<br />
[http://repo1.maven.org/maven2], то его требуется упаковать а также добавить фрагмент depmap с <br />
помощью %add_to_maven_depmap.<br />
<br />
== Ссылки ==<br />
<br />
=== ALT Linux Java Packaging HOWTO ===<br />
{{Main|Java/HOWTO}}<br />
=== ALT Linux Java Packaging FAQ ===<br />
{{Main|Java/JavaPackagingFAQ}}<br />
=== Шаблоны spec-файлов ===<br />
[[Java/JPackageSpecTemplate|JPackage Spec Template]] — шаблон spec-файла для java-приложений из JPackage, адаптированный для сизифа.<br />
<br />
[[SampleSpecs/javalib| javalib Spec Template]] — шаблон spec-файла для java-библиотеки, собираемой с помощью ant.<br />
<br />
=== Другие ресурсы ===<br />
<br />
[http://fedoraproject.org/wiki/Java Java on FedoraWiki]<br />
<br />
{{Category navigation|title=Java|category=Java|sortkey=*}}</div>195.160.222.83https://www.altlinux.org/index.php?title=Gear/cronbuild&diff=16189Gear/cronbuild2010-09-06T15:24:49Z<p>195.160.222.83: /* Введение в cronbuild. */</p>
<hr />
<div>{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}<br />
<!-- {{stub}} --><br />
<br />
== Введение в cronbuild. ==<br />
<br />
Некоторые пакеты по своей природе нуждаются в постоянном обновлении,<br />
при этом при обновлении у этих пакетов спек практически не меняется.<br />
К таким пакетам относятся различные базы - антивирусные, оборудования<br />
(foomatic-db, PCI IDs, мониторов, ...), cliparts, и т. д.<br />
Как правило, в версии/релизе таких пакетов присутствует timestamp.<br />
Система cronbuild предназначена для автоматизации сборки таких пакетов.<br />
Теперь майнтайнеру достаточно один раз настроить для пакета cronbuild<br />
и пакет будет автоматически собираться в Сизиф с заданной майнтайнером периодичностью,<br />
например, раз в неделю, до тех пор, пока сборка не сломается.<br />
<br />
При этом пакеты собираются только тогда, когда это действительно нужно:<br />
если после обновления файлы исходников не изменились (согласно git diff <commit before update>),<br />
то сборка пакета будет пропущена, так как в ней нет необходимости.<br />
<br />
Управлять роботом очень легко: если нужно внести в пакет какие-то изменения,<br />
просто внесите их локально и отправьте пакет на сборку вручную.<br />
Робот автоматически подхватит вашу работу.<br />
<br />
== Настройка cronbuild. ==<br />
cronbuild состоит из 3-х частей:<br />
<br />
* локальные скрипты cronbuild для автоматизации обновления .git репозитрия.<br />
* утилиты для локальной сборки (пакет {{pkg|gear-cronbuild}})<br />
* сервер удаленной сборки (cronbuild repocop.altlinux.org)<br />
<br />
=== локальные скрипты cronbuild для автоматизации обновления .git репозитрия ===<br />
<br />
Сердцем cronbuild является скрипт {{cmd|.gear/cronbuild-update-source}}.<br />
Этот скрипт пишется индивидуально для каждого пакета. Его задача --<br />
обновить исходные тексты пакета, используя {{cmd|git-fetch}}, {{cmd|git-svn}}<br />
или просто {{cmd|wget}}. <br />
<br />
==== пример скрипта для обновления через wget ====<br />
Этот скрипт работает в случае, когда исходники публикуются в виде тарбола,<br />
а в git репозитарии хранятся в распакованном виде в поддиректории {{term|$PKGNAME}}.<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
PKGNAME=<...><br />
rm -f $PKGNAME-SNAPSHOT.tar.gz<br />
wget -c http://www.pkgname.org/download/pkgname/pkgname-SNAPSHOT.tar.gz<br />
tar xzf $PKGNAME-SNAPSHOT.tar.gz<br />
rm -f $PKGNAME-SNAPSHOT.tar.gz<br />
git rm -r -f $PKGNAME<br />
rm -rf $PKGNAME<br />
mv $PKGNAME-SNAMPSHOT $PKGNAME<br />
git add $PKGNAME<br />
</source><br />
<br />
==== замечания к скрипту ====<br />
* скрипт должен сообщать о всех проблемах при обновлении. Проще всего использовать {{path|#!/bin/sh -ve}},<br />
иначе придется у каждой команды проверять код завершения.<br />
* изменения должны быть добавлены в индекс git. <br />
* не нужно коммитить изменения: git-cronbuild это сделает автоматически после успешной сборки.<br />
<br />
==== Изменение версии/релиза пакета ====<br />
Утилита {{cmd|gear-cronbuild-update-spec-timestamp}}<br />
автоматически ищет и обновляет timestamp вида ГГГГММДД<br />
в тегах Serial, Epoch, Version, Release, либо в<br />
декларациях {{cmd|%define <macrosname> <timestamp>}}.<br />
Если пакет использует другую систему нумерации,<br />
необходимо создать свой скрипт изменения версии/релиза пакета<br />
{{path|.gear/cronbuild-update-version}}.<br />
Также можно переопределить стандартный changelog скриптом<br />
{{path|.gear/cronbuild-add-changelog}}.<br />
В теле этого скрипта должна быть вызвана команда {{cmd|add_changelog}}<br />
с желаемым текстом.<br />
<br />
=== утилиты для локальной сборки (пакет {{pkg|gear-cronbuild}}) ===<br />
Для того, чтобы пользоваться скриптами cronbuild на локальной машине, необходимо установить пакет {{pkg|gear-cronbuild}}.<br />
Команда {{prg|gear-cronbuild-apply-hooks}} обновляет git репозиторий до следующей версии.<br />
Для удобства пользователя есть скрипт-обертка {{prg|gear-cronbuild}},<br />
который обновляет репозиторий, собирает пакет, и в случае успеха, коммитит изменения.<br />
<br />
скрипт-обертка {{prg|gear-cronbuild}}:<br />
<source lang="bash"><br />
#!/bin/sh -ve<br />
gear-cronbuild-apply-hooks<br />
gear "$@"<br />
gear-commit<br />
</source><br />
<br />
=== сервер удаленной сборки (cronbuild repocop.altlinux.org) ===<br />
<br />
локальные утилиты gear-cronbuild имеют тот недостаток, что <br />
их надо не забывать запускать. Кроме того, они не автоматизируют отправку пакета в Сизиф.<br />
<br />
Сервер удаленной сборки cronbuild в песочнице repocop.altlinux.org<br />
позволяет автоматизировать сборку пакетов полностью.<br />
<br />
==== Как поставить пакет на сборку ====<br />
<br />
Если пакет успешно собирается с помощью gear-cronbuild локально,<br />
пришло время поставить его на автоматическую сборку.<br />
<br />
Для этого необходимо создать файл {{path|.gear/cronbuild-options}},<br />
указать там желаемую периодичность сборки и e-mail для рассылки оповещений,<br />
и зарегистрировать в bugzilla заявку на Infrastructure/cronbuild<br />
(пока это не реализовано, можно на пакет gear-cronbuild).<br />
<br />
==== Как вносить изменения в сборку ====<br />
<br />
сервер сборки поддерживает 2 системы транспорта:<br />
сборка по тегу из git+gear репозитория<br />
и сборка из srpm.<br />
<br />
* Сборка по тегу из git+gear репозитория.<br />
Управление сборкой устроенно очень просто:<br />
сервер клонирует последнюю успешную сборку в Сизиф<br />
и применяет к ней gear-cronbuild.<br />
Поэтому, если вы хотите починить или улучшить<br />
автоматическую сборку, просто соберите пакет вручную,<br />
и в дальнейшем автоматическая сборка будет идти на ее основе.<br />
<br />
* сборка из srpm.<br />
считается экспериментальной.<br />
<br />
== Приложения. ==<br />
=== Полный список служебных файлов cronbuild в {{path|.gear/}} ===<br />
{| class="standard"<br />
!файл<br />
!Описание<br />
|-<br />
|class="shadow"|cronbuild-update-source<br />
|Основной скрипт для обновления содержимого пакета.<br />
|-<br />
|class="shadow"|cronbuild-update-version<br />
| Скрипт для обновления версии и/ли релиза пакета. Не обязателен.<br />
|-<br />
|class="shadow"|cronbuild-add-changelog<br />
| Скрипт для кастомизации changelog. Не обязателен.<br />
|-<br />
|class="shadow"|cronbuild-options<br />
| Конфигурационный файл. Не обязателен.<br />
|}<br />
Скрипты должны быть помечены как исполняемые.<br />
К файлам конфигурации это не относится.<br />
<br />
Скрипты получают спек-файл как первый аргумент.<br />
<br />
=== cronbuild-options ===<br />
{| class="standard"<br />
!переменная<br />
!Описание<br />
|-<br />
|class="shadow"|cronbuild_requires<br />
|набор дополнительных пакетов, который будет передан в hsh-install для установки в chroot.<br />
необходим, если скрипты используют утилиты, не входящие в базовый набор (curl, wget, git, unzip, ...)<br />
|-<br />
|class="shadow"|cronbuild_interval<br />
|периодичность сборок в днях. желательно.<br />
|-<br />
|class="shadow"|cronbuild_mailto<br />
|e-mail ответственного. обязательно.<br />
|-<br />
|class="shadow"|cronbuild_cc<br />
|список дополнительных e-mail (optional)<br />
|-<br />
|class="shadow"|cronbuild_mastergit<br />
|experimental<br />
|-<br />
|class="shadow"|cronbuild_masterbranch<br />
|experimental<br />
|}<br />
<br />
=== Пример использования .gear/cronbuild-* ===</div>195.160.222.83https://www.altlinux.org/index.php?title=FindLang_Policy&diff=13701FindLang Policy2010-02-27T14:37:15Z<p>195.160.222.83: /* Общие положения. */</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=viy@<br />
|discussion_link=<br />
|discussion_since=26.02.2010<br />
}}<br />
Policy по применению %find_lang.<br />
<br />
== Общие положения. ==<br />
<br />
* Языкозависимые файлы, отсутствие которых не нарушает работы программы,должны быть помечены как %lang.<br />
<br />
* Рекомендуется для создания списков таких файлов использовать, где это возможно, встроенную команду %find_lang.<br />
<br />
* Допускается (из-за особенностей реализации %find_lang, см. [http://lists.altlinux.org/pipermail/devel/2010-February/180492.html письмо]) не помечать файлы для языка en, в том числе .mo файлы.<br />
<br />
* .po файлы, установленные в {{path|/usr/share/locale/*/*.po}}, должны быть конвертированы в .mo формат.<br />
<br />
== Использование %find_lang ==<br />
%find_lang вызывается в секции %install<br />
<br />
Для программ GNOME указывается:<br />
<pre>%find_lang --with-gnome %name</pre><br />
<br />
При этом find-lang кроме файлов переводов в %_datadir/locale ищет файлы справки Гном в %_datadir/gnome/help и .omf файлы в %_datadir/omf<br />
<br />
Поэтому не нужно указывать в секции %files каталоги с locale (переводами), а также<br />
%_datadir/omf/%name<br />
%_datadir/gnome/help/<br />
<br />
Для программ KDE указывается:<br />
<pre>%find_lang --with-kde %name</pre><br />
При этом find-lang ищет файлы справки KDE в %_defaultdocdir/HTML<br />
<br />
<br />
Далее секция %files оформляется следующим образом:<br />
%files -f %name.lang<br />
<br />
%find_lang, являющийся скриптом, имеет и другие параметры, делающие его более гибким.</div>195.160.222.83https://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=13378Java/JavaPackagingFAQ2010-01-24T15:34:49Z<p>195.160.222.83: /* Hasher */</p>
<hr />
<div>{{Викифицировать}}<br />
<br />
__TOC__<br />
<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть compat-пакеты одной и той же библиотеки разных версий с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt>.<br />
:2) есть переименованные пакеты и пакеты со старым именем с совместимым содержимым.<br />
:Например xmlgraphics-batik и batik.<br />
:последние уходят в Obsolete после окончания переезда на новое имя.<br />
----<br />
<br />
==== Что означает jpp5 в релизе? ====<br />
<br />
Пакеты, импортированные роботом из JPackage и Fedora, имеют релиз вида<br />
alt<M>_<N>jpp<K>, где M - релиз в альт, N - релиз в JPackage или Fedora,<br />
K - версия JVM, для которой собран данный пакет.<br />
Текущие значения:<br />
* 1.7 (от JPackage 1.7) java 1.4 и выше<br />
* 5 (от JPackage 5 и Java 5) java 1.5 и выше<br />
* 6 (от JPackage 6 и Java 6) java 1.6 и выше<br />
<br />
Пакеты, собранные человеком, для которых нет аналога в Fedora/JPackage, имеют релиз вида<br />
alt<M>_jvm<K>, где M - релиз в альт, <br />
K - версия JVM, для которой собран данный пакет.<br />
Текущие значения:<br />
* 5 (от Java 5) java 1.5 и выше<br />
* 6 (от Java 6) java 1.6 и выше<br />
<br />
Это удобно: не заглядывая в пакет, можно сказать, под какими JVM он будет запускаться,<br />
а под какими нет.<br />
<br />
==== Нужен ли Epoch: в java пакетах? ====<br />
<br />
Не нужен, если это оригинальный пакет для ALT Linux.<br />
<br />
Однако, в импортированных пакетах, а их большинство из имеющихся, стоит Epoch:0 и выше.<br />
Это нужно для совместимости с JPackage. <br />
Epoch:0 разные версии rpm обрабатывают по-разному, поэтому, чтобы не зависеть от rpm.<br />
JPackage пакеты всегда имеют Epoch: и часто ссылаются на другие пакеты с явным указанием <br />
Epoch:, например, Requires: jakarta-commons-cli >= 0:1.1<br />
<br />
Поэтому для частичной сборочной и установочной совместимости все пакеты, которые<br />
соответствуют пакетам из JPackage, должны иметь Epoch: не меньше того, который в JPackage.<br />
<br />
Для оригинальных пакетов ALT Linux, аналог которых в JPackage отсутствует,<br />
Epoch: указывать не нужно.<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
;viy > <br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
:он генерирует списки всех java пакетов в Сизифе с владельцами согласно acl.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да, это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не обязательно, но желательно.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозиторием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
==== Обсуждение определителя зависимостей и загрузчика классов ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/subject.html [devel]] Java: no magic wand / [devel] Java: no magic wand, no magic hammer<br />
начиная с [http://lists.altlinux.org/pipermail/devel/2008-January/068361.html http://lists.altlinux.org/pipermail/devel/2008-January/068361.html].<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Почему у java-пакета дикие зависимости? ====<br />
<br />
ОТВЕТ: эти библиотеки, вообще говоря, друг другу по зависимостям нужны, так как в каких-то случаях используются.<br />
<br />
Это то же самое, если gnomer/gtkшник поставил<br />
себе какой-нибудь kfurrent, а тот ему пол kde в систему втянул.<br />
Никто же по этому поводу не ругается и не предлагает<br />
линковать kfurrent с qt4 и kde libs статически.<br />
<br />
Да, первый kde пакет затянет в систему пол kde, зато потом<br />
второй kde пакет и последующие ничего в систему тянуть не будут.<br />
<br />
Почему же такое возмущение по поводу java?<br />
<br />
Там то же самое:<br />
первый java пакет затянет в систему пол java, зато потом<br />
второй java пакет и последующие ничего в систему тянуть не будут.<br />
Кто хочет без зависимостей, ставьте себе в хомяк.<br />
<br />
см. тж. обсуждение <br />
https://bugzilla.altlinux.org/show_bug.cgi?id=18456<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
Также man hasher-priv.conf<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
<pre><br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
Nov 26, 2007 Slava Dubrovskiy wrote:<br />
> На выходных сделал подход к снаряду. <br />
> На текущей пакетной базе это <br />
> сделать нельзя, т.к. в репозитории нет плагинов и pom которые нужны для<br />
> сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
<br />
Это достаточно скоро будет.<br />
> Собрал с закачкой из инета после чего локальный репозиторий (папка .m2) <br />
> стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в <br />
> репозиториях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br />
наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
</pre><br />
----<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
<br />
<pre><br />
Jan 29, 2008 <br />
Alexey I. Froloff wrote: <br />
> $ sudo apt-get install jakarta-commons-cli log4j<br />
> The following NEW packages will be installed:<br />
> jpackage-utils log4j rpm-build-java<br />
</pre><br />
<br />
;raorn ><br />
:.o0( ох проклянут меня за азуреусовские зависимости... )<br />
;viy ><br />
:скорее за их отсутствие :)<br />
:если не будет зависимостей, средняя софтина на java <br />
:будет тянуть 40-200 Mb. 1 софтина как весь <br />
:дистрибутив. а так они разделяют зависимости...<br />
:не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
:[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
:Особенно смущают jpackage-utils и rpm-build-java.<br />
:jpackage-utils здесь потому, что в log4j есть приложения.<br />
:для их запуска рекомендуется строить classspath с помощью<br />
:скрипта build-classpath<br />
:а не указывать библиотеки явно.<br />
<br />
:Например<br />
:<tt>java -cp \<br />
:$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
:<class></tt><br />
<br />
:Кстати, это советую сделать для azaureus.<br />
<br />
:с rpm-build-java, боюсь, findreq наshellил.<br />
:в свободное время посмотрю.<br />
<br />
;raorn > <br />
:а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
;viy > <br />
:надо, но руки не доходят... увы, не многорукое Шиво...<br />
:там java-common Миши Забалуева был по сути попыткой написать <br />
:jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
;raorn > <br />
:ага, я видел. вкусные функции там<br />
:а дока есть? или экспортируемые переменные большой секрет?<br />
;viy > <br />
:дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
:документация разная есть, в процессе написания, сейчас брошу ссылки<br />
:[http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
:1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
----<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
;raorn ><br />
:а ещё build-classpath не умеет абсолютные пути к жарам<br />
;viy > <br />
:в смысле? нельзя ж абсолютные пути.<br />
;raorn > <br />
:у меня софтина в /usr/share/azureus/Azureus2.jar<br />
:или в %_javadir положить?<br />
:я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
:он находит Azureus2.jar<br />
<br />
;viy > <br />
:по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:библиотека ищется в нескольких местах<br />
;raorn > <br />
:это я уже подсмотрел<br />
<br />
;viy > <br />
:проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
:у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
:что касается /usr/share/azureus/Azureus2.jar --<br />
:если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
:и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
:если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
;raorn > <br />
:это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
;viy > <br />
:юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
;raorn > <br />
:а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
:это в корне неверно?<br />
;viy > <br />
:да, неверно. граблей слишком много,<br />
;raorn > <br />
:я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
:но если говоришь надо - переделаю ;-)<br />
:мне ещё наверно зымбру собирать...<br />
;viy > <br />
:_javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
:('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
:а от явного указания и в /opt не скроешься.<br />
;raorn > <br />
:ну тогда ладно<br />
<br />
----<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
<pre><br />
%set_classpath %_javadir/junit.jar<br />
export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
%ant_build \<br />
%ant \<br />
</pre><br />
<br />
<pre><br />
Jul 23, 2008 <br />
Kirill Maslinsky wrote: <br />
> > export CLASSPATH=$(build-classpath junit) <br />
> Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.<br />
</pre><br />
<br />
----<br />
<br />
==== Q: будут ли еще какие-либо макросы для сборки с помощью ant, кроме %ant ? ====<br />
<br />
A: Нет, к сожалению, универсальные макросы для %ant<br />
не возможны по самой природе ant.<br />
файлы build.xml по своей природе подобны<br />
самописанным Makefile.<br />
По той же причине для make не существует универсальных<br />
макросов, кроме %make.<br />
<br />
Хорошей иллюстрацией к сказанному служат наши макросы<br />
%make_install, %makeinstall_std… итд.<br />
<br />
Эти макросы возможны потому, что большинство пакетов<br />
собирается autotools. Поэтому у них Makefile генерированы,<br />
а у генерированных Makefile, в отличие от самописанных<br />
Makefile, соблюдаются определенные соглашения,<br />
что и позволяет создавать дополнительные макросы.<br />
Эти дополнительные макросы с самописанной системой сборки<br />
работать не будут. Другое дело, что для С в большинстве своем<br />
самописанные системы сборки вымерли :)<br />
<br />
файлы build.xml у нас в основном не генерируются,<br />
и соблюдения каких-либо доп. соглашений от них ожидать нельзя.<br />
<br />
{{Category navigation|title=Java|category=Java|sortkey={{SUBPAGENAME}}}}<br />
{{Category navigation|title=FAQ|category=FAQ|sortkey={{SUBPAGENAME}}}}</div>195.160.222.83https://www.altlinux.org/index.php?title=Repocop&diff=12508Repocop2009-10-22T19:57:59Z<p>195.160.222.83: /* Тесты-постпроцессоры */</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
[[Категория:Devel]]<br />
<!--MovedFromFreesourceInfo|AltLinux/Sisyphus/Tools/Repocop--><br />
[[Изображение:Robocop-12inch-5-01.jpg|tumb|left]]<br />
[http://absurdopedia.wikia.com/wiki/Огромный_боевой_робот Малый огромный боевой робот], созданный [http://absurdopedia.wikia.com/wiki/Безумные_учёные безумными учёными]<br />
для тестирования отдельных rpm пакетов или всего Сизифа.<br />
<br />
В отличие от [[sisyphus_check|sisyphus_check]], который настолько суров, что сначала убивает возможного<br />
нарушителя, а потом его допрашивает, repocop в открытый бой не вступает, ограничиваясь<br />
невнятными выкриками на американском английском и показом красных и жёлтых карточек.<br />
<br />
Другими словами, repocop представляет собой платформу для запуска интеграционных тестов.<br />
В её состав входит собственно пускатель тестов, различные генераторы отчётов из полученных результатов,<br />
а также генератор патчей для исправления найденных ошибок, если это возможно.<br />
Сами тесты в repocop не входят. Тесты оформлены как отдельные пакеты, поэтому набор тестов легко конфигурируется.<br />
<br />
Результаты ежедневного тестирования Sisyphus публикуются на [http://repocop.altlinux.org/pub/repocop/reports/ repocop.altlinux.org]<br />
а так же доступны через web-интерфейс prometeus на [http://sisyphus.ru/ sisyphus.ru].<br />
<br />
Например, для мейнтейнера {{man|viy}} удобными ссылками на результаты тестирования будут: [http://www.sisyphus.ru/packager/viy/srpms по пакетам], [http://repocop.altlinux.org/pub/repocop/reports/txt/by-acl/viy.txt по ACL] и [http://repocop.altlinux.org/pub/repocop/reports/txt/by-packager/viy.txt по сборщику].<br />
Сгенерированные патчи можно просмотреть:<br />
[http://repocop.altlinux.org/pub/repocop/reports/diff/by-acl/viy/ по ACL] и [http://repocop.altlinux.org/pub/repocop/reports/diff/by-packager/viy/ по сборщику].<br />
<br />
__TOC__<br />
<br />
=== Установка ===<br />
<br />
Установка repocop на локальной машине:<br />
<source lang="bash"><br />
apt-get install repocop repocop-unittest<br />
</source><br />
<br />
repocop состоит из следующих пакетов:<br />
{| class="standard"<br />
!Пакет<br />
!Описание<br />
|-<br />
|class="shadow"|repocop<br />
|Основной пакет<br />
|-<br />
|class="shadow"|repocop-tools<br />
| Инструменты для исправления пакетов силами repocop. Не обязателен.<br />
|-<br />
|class="shadow"|repocop-prometeus<br />
|Плагин к prometeus. Не нужен при обычной установке<br />
|}<br />
<br />
Сами тесты вместе с пакетом не идут, их надо устанавливать отдельно.<br />
<br />
Полный список тестов можно посмотреть на [http://sisyphus.ru/find.shtml?request=repocop-unittest sisyphus.ru].<br />
<br />
Для удобства виртуальный пакет repocop-unittest позволяет установить все официальные тесты, которые используются в sisyphus-cybertalk@ и на [http://sisyphus.ru/ sisyphus.ru].<br />
<br />
=== Запуск repocop для тестирования пакетов ===<br />
<br />
* Пример запуска repocop для тестирования свежесобранных пакетов:<br />
*: {{cmd|repocop-run ~/hasher/repo/*/RPMS.hasher/*.rpm}}<br />
* Пример запуска repocop для тестирования репозитория:<br />
*: {{cmd|repocop-run /var/ftp/pub/Linux/ALT/Sisyphus/files/{noarch,i586}/RPMS}}<br />
<br />
При повторном запуске будут тестироваться только новые пакеты, так как результаты тестов кешируются<br />
в <repocop cache dir>. По умолчанию <repocop cache dir> равно <tt>~/.repocop</tt>.<br />
Значение по умолчанию для <repocop cache dir> можно переопределить с помощью опции -c <repocop cache dir><br />
либо поменять с помощью переменной окружения REPOCOP_CACHEDIR. Например, так:<br />
<tt>export REPOCOP_CACHEDIR=/tmp/.private/user/repocop</tt>.<br />
<br />
Для ухода за кешем используются утилиты <tt>repocop-purge-* </tt>.<br />
<br />
{| class="standard"<br />
!Утилита<br />
!Описание<br />
|-<br />
|class="shadow"|repocop-purge-except<br />
|очистить все записи, кроме относящихся к пакетам, данным как аргументы.<br />
|-<br />
|class="shadow"|repocop-purge-given<br />
|очистить все записи, относящиеся к пакетам, данным как аргументы.<br />
|}<br />
<br />
полезная опция <tt>-l (--last-run)</tt> означает «все пакеты, которые repocop-run тестировал при последнем запуске».<br />
Таким образом, сразу после запуска repocop-run для проверки всего репозитория имеет смысл вызвать<br />
<tt>repocop-purge-except --last-run</tt>, чтобы устаревшие данные из кеша не попали в отчёт,<br />
а сразу после запуска repocop-run для проверки пробной сборки имеет смысл вызвать<br />
<tt>repocop-purge-given --last-run</tt>, чтобы удалить из кеша данные о пробной сборке, ещё не попавшей в репозиторий.<br />
<br />
Результаты тестов можно просмотреть либо непосредственно в кеше, либо воспользоваться каким-либо<br />
генератором отчетов, например, <tt>repocop-report-txt</tt>.<br />
<tt>repocop-report-txt</tt> обработает кеш и сложит результаты тестов в читабельном виде<br />
в подпапку <repocop cache dir>/reports/txt/.<br />
<br />
==== Тестирование свежесобранных пакетов с помощью repocop-check ====<br />
<br />
Утилита <tt>repocop-check</tt> — busybox для занятого майнтайнера. Позволяет в одном вызове проверить<br />
свежесобранные пакеты. (Сделано по заявке Дамира @damir).<br />
<br />
Пример вызова:<br />
repocop-check /hasher/repo/*/RPMS/hasher /hasher/repo/SRPMS/hasher<br />
<br />
Опция <tt>--newer <filename></tt> позволяет дополнительно отфильтровать те пакеты, которые новее, чем<br />
указанный <filename>.<br />
<br />
Исходный код.<br />
<source lang="bash"><br />
#!/bin/sh -e<br />
repocop-run -q "$@"<br />
repocop-report-stdout "$@"<br />
repocop-purge-given --no-db-vacuum -q "$@"<br />
</source><br />
<br />
==== Уход за кешем с помощью repocop-purge-* ====<br />
<br />
Для ухода за кешем используются утилиты <tt>repocop-purge-* </tt>.<br />
<br />
{| class="standard"<br />
!Утилита<br />
!Описание<br />
|-<br />
|class="shadow"|repocop-purge-except<br />
|очистить все записи, кроме относящихся к пакетам, данным как аргументы.<br />
|-<br />
|class="shadow"|repocop-purge-given<br />
|очистить все записи, относящиеся к пакетам, данным как аргументы.<br />
|} <!-- Почему-то второй раз таблица повторяется и описание к ней... Баг? --><br />
<br />
опция <tt>-l (--last-run)</tt> означает «все пакеты, которые repocop-run тестировал при последнем запуске».<br />
Опция <tt>-l</tt> по своей природе очень коварна, так как человек через минуту забывает, что именно он<br />
запускал последний раз. Так что рекомендуется использовать её больше в скриптах.<br />
<br />
пример вызова <tt>repocop-purge-* </tt> для очистки кеша от устаревших пакетов:<br />
repocop-purge-except /var/ftp/pub/Linux/ALT/Sisyphus/files/{SRPMS,i586/RPMS,i386/RPMS,noarch/RPMS}<br />
<br />
==== Пример автоматизации тестирования репозитория с помощью repocop ====<br />
<br />
Указанный скрипт можно запускать после каждого обновления дистрибутива,<br />
руками или через cron.<br />
<source lang="bash"><br />
#!/bin/sh<br />
# you may choose alternative path to cachedir<br />
export REPOCOP_CACHEDIR=~/.repocop<br />
<br />
# edit paths to repository below !!!<br />
repocop-run /var/ftp/pub/Linux/ALT/Sisyphus/files/{noarch,i586}/RPMS<br />
<br />
repocop-purge-except --last-run<br />
repocop-report-txt >/dev/null<br />
</source><br />
<br />
=== Запуск repocop для исправления пакетов ===<br />
{{Main|Repocop/RepairMiniHOWTO}}<br />
<br />
=== Как писать тесты для repocop ===<br />
<br />
Тест в общем случае состоит из нескольких исполняемых файлов и файлов данных со специальными именами,<br />
которые собраны в одном каталоге вида <tt><testname>/</tt>.<br />
Исполняемые файлы, входящие в тест, получают аргументы через переменные.<br />
Тест возвращают значение через вызов одной из команд repocop-test-skip, repocop-test-ok, repocop-test-warn, repocop-test-fail.<br />
Возвратить значение для каждого пакета нужно ровно 1 раз.<br />
<br />
{| class="standard"<br />
!Команда<br />
!Описание<br />
|-<br />
|repocop-test-skip<br />
|тесту нечего проверять в данном пакете.<br />
|-<br />
|repocop-test-ok<br />
|пакет попадает под определение теста и с ним все в порядке.<br />
|-<br />
|repocop-test-experimental<br />
|ошибок нет, но тест советует сделать экспериментальное/разрабатываемое изменение.<br />
|-<br />
|repocop-test-info<br />
|ошибок нет, есть замечания к пакету, пакет можно сделать лучше.<br />
|-<br />
|repocop-test-warn<br />
|несущественная ошибка, пакет можно сделать лучше.<br />
|-<br />
|repocop-test-fail<br />
|найдена существенная ошибка.<br />
|}<br />
<br />
repocop-test-info, repocop-test-warn, repocop-test-fail в качестве аргументов принимают сообщение об ошибке.<br />
Дополнительная опция -k |--key <REPOCOP_PKG_KEY> позволяет явно указать пакет.<br />
Подробнее использование этой опции будет разобрано в разделе «Тесты-постпроцессоры».<br />
<br />
Многие тесты совместно используют одни и те же данные. Примером может служить база данных rpm.db,<br />
которая создаётся в процессе работы repocop. Для каждого пакета в ней содержатся список файлов, значения<br />
полей Group:, URL:, Requires:, Provides, скрипты %postun, и т. д., то есть вся информация, которая содержится<br />
в заголовке rpm пакета.<br />
<br />
Кроме того, логика обработки данных меняется гораздо чаще, чем структура хранения данных.<br />
Чтобы повысить повторную используемость кода и не прогонять весь репозиторий через тесты каждый раз,<br />
когда в тесте меняется логика, в repocop 0.07 введена новая сущность — коллекторы (сборщики данных).<br />
Коллекторы устроены в точности как тесты, но не возвращают никаких результатов, только собирают данные для своей базы.<br />
Собранные коллекторами данные могут использоваться в тестах при вызове скриптов <testname>/done.<br />
<br />
Это позволяет дорогие по машинному времени вызовы <testname>/test сосредоточить в коллекторах, а<br />
в тестах использовать дешёвые вызовы <testname>/done.<br />
<br />
Рекомендуемый формат хранения собранных коллектором данных — файл SQLite. Архитектура repocop<br />
не запрещает альтернативные форматы хранения, но разнородные форматы данных могут затруднить<br />
обработку данных тестами. Например, данные из разных файлов SQLite можно обработать одним запросом<br />
SQLite, чего не скажешь о разнородных форматах.<br />
<br />
==== Предопределённые имена для файлов, входящих в тест ====<br />
<br />
{| class="standard"<br />
!Имя!!Mode!!Функция<br />
|-<br />
|<testname>/init.sql.x||align="center"|644||Инициализация схемы БД под SQLite. X — версия схемы<br />
|-<br />
|<testname>/upgrade.sql.Y||align="center"|644||Скрипты обновления схемы БД до версии Y на SQL<br />
|-<br />
|<testname>/upgrade||align="center"|755||Общий скрипт обновления схемы БД. Используется в случае, когда SQL недостаточно<br />
|-<br />
|<testname>/init||align="center"|755||Инициализатор коллекторов и попакетных тестов. Запускается 1 раз при запуске repocop<br />
|-<br />
|<testname>/options||align="center"|755||Дополнительные настройки для теста. Читается 1 раз в начале работы repocop<br />
|-<br />
|<testname>/test||align="center"|755||Обработчик пакетов. Будет запуcкаться для каждого обрабатываемого пакета<br />
|-<br />
|<testname>/done||align="center"|755||Деструктор коллекторов и попакетных тестов. запускается 1 раз в конце работы repocop<br />
|-<br />
|<testname>/purge||align="center"|755||Удаление устаревших записей из собственного кеша теста. Вызывается утилитами repocop-purge-*<br />
|-<br />
|<testname>/purge.sql||align="center"|644||Удаление устаревших записей из собственной БД теста. Вызывается утилитами repocop-purge-*<br />
|-<br />
|<testname>/posttest||align="center"|755|| Обработчик коллекторов. запускается 1 раз в конце работы repocop<br />
|-<br />
|<testname>/description||align="center"|644||Описание теста. Не используется, но возможно использование в будущем<br />
|}<br />
<br />
==== Упаковка тестов по каталогам в rpm пакете ====<br />
{| class="standard"<br />
!Имя<br />
!Описание<br />
|-<br />
|%_datadir/repocop/pkgtests/%testname/*<br />
|тест бинарных пакетов<br />
|-<br />
|%_libdir/repocop/pkgtests/%testname/*<br />
|тест бинарных пакетов<br />
|-<br />
|%_datadir/repocop/pkgcollectors/%testname/*<br />
|коллектор бинарных пакетов<br />
|-<br />
|%_libdir/repocop/pkgcollectors/%testname/*<br />
|коллектор бинарных пакетов<br />
|-<br />
|%_datadir/repocop/srctests/%testname/*<br />
|тест исходных пакетов<br />
|-<br />
|%_libdir/repocop/srctests/%testname/*<br />
|тест исходных пакетов<br />
|-<br />
|%_datadir/repocop/srccollectors/%testname/*<br />
|коллектор исходных пакетов<br />
|-<br />
|%_libdir/repocop/srccollectors/%testname/*<br />
|коллектор исходных пакетов<br />
|}<br />
<br />
==== Тесты без состояния ====<br />
<br />
простейшим примером тестов являются тесты без состояния,<br />
которые помнят только текущий пакет и сразу выдают сообщение об ошибке.<br />
Таким тестам не нужны <tt><testname>/init</tt> и <tt><testname>/done</tt>.<br />
Они состоят из единственного скрипта <tt><testname>/test</tt>.<br />
<br />
<tt><testname>/test</tt> вызывается для тех пакетов, которые ещё не обрабатывались этим тестом.<br />
Если файл <tt><testname>/test</tt> новее, чем результаты тестов, то они удаляются как устаревшие<br />
и соответствующие пакеты проходят тест заново.<br />
<br />
Аргументы <tt><testname>/test</tt>:<br />
<br />
* REPOCOP_PKG_ROOT — директория<br />
* REPOCOP_PKG_KEY — внутренний id пакета в базах repocop. Используется в тестах с состоянием<br />
* REPOCOP_PKG — полный путь к пакету<br />
также доступны:<br />
* REPOCOP_PKG_NAME<br />
* REPOCOP_PKG_VERSION<br />
* REPOCOP_PKG_RELEASE<br />
* REPOCOP_PKG_EPOCH<br />
<br />
тест без состояния упаковывается в rpm как %_datadir/repocop/pkgtests/%testname/test<br />
либо как %_libdir/repocop/pkgtests/%testname/test, в зависимости от языка, на котором он написан.<br />
<br />
Простейший тест на shell:<br />
<source lang="bash"><br />
#!/bin/sh<br />
grep -s -q -r $REPOCOP_PKG_NAME-buildroot $REPOCOP_PKG_ROOT/ && \<br />
exec repocop-test-fail "found paths to buildroot:" || exec repocop-test-ok<br />
</source><br />
тест не совсем корректный, так как на самом деле нужно искать $REPOCOP_SRC_NAME-buildroot (damir@)<br />
<br />
Пример спек-файла для упаковки теста repocop без состояния.<br />
<pre>%define testname sampletest<br />
<br />
Name: repocop-unittest-%testname<br />
Version: 0.01<br />
Release: alt1<br />
BuildArch: noarch<br />
Packager: Igor Yu. Vlasenko <viy@altlinux.org><br />
<br />
Summary: %testname integration tests for repocop test platform<br />
Group: Development/Other<br />
License: GPL or Artistic<br />
<br />
%description<br />
The test warns package maintainers that ...<br />
<br />
%prep<br />
<br />
%build<br />
cat > test <<'EOF'<br />
#!/bin/bash<br />
# enter your test here<br />
EOF<br />
<br />
%install<br />
mkdir -p %buildroot%_datadir/repocop/pkgtests/%testname/<br />
install -m 755 test %buildroot%_datadir/repocop/pkgtests/%testname/<br />
<br />
%files<br />
%_datadir/repocop/pkgtests/%testname<br />
<br />
%changelog</pre><br />
==== Корректное использование сторонних утилит в тестах ====<br />
<br />
Если тест вызывает для проверки пакетов сторонние утилиты, такие, как {{prg|sisyphus_check}} или {{prg|desktop-file-validate}},<br />
то полученные результаты теста зависят не только от пакета и самого теста, но и от версии сторонней утилиты.<br />
Поэтому корректный тест при изменениях в сторонней утилите должен сбрасывать результаты тестов.<br />
Для сброса результатов тестов достаточно поменять timestamp у скрипта test.<br />
<br />
'''Пример оформления проверки в rpm пакете с помощью rpm trigger.'''<br />
<pre><br />
%triggerin -- sisyphus_check<br />
# if test itself is installed/updated, just keep build timestamp<br />
[ $2 = 1 ] && exit 0 ||:<br />
# at every sisyphus_check upgrade we should bump timestamp<br />
# to discard cached results of old sisyphus_check<br />
touch %_datadir/repocop/pkgtests/%testname/test<br />
</pre><br />
<br />
Заметим, что без дополнительной проверки <br />
<pre><br />
[ $2 = 1 ] && exit 0 ||:<br />
</pre><br />
trigger вызывался бы и при установке/обновлении самого теста.<br />
Это было бы плохо тем, что в результате невозможно было бы использовать кеш тестов repocop,<br />
доступный в песочнице repocop.altlinux.org: почти всегда на локальной машине timestamp соответствующего теста был бы новее, чем у<br />
теста, использующегося в песочнице.<br />
<br />
==== Тесты с состоянием ====<br />
<br />
Тест общего вида инициализирует своё состояние с помощью <tt><testname>/init.sql.*</tt>, (в общем случае — при вызове <tt><testname>/init</tt>).<br />
По мере прохождения тест может накапливать информацию о пакетах, используя <testname>/test,<br />
а в конце работы обработать её и сообщить о найденных ошибках в скрипте <testname>/done.<br />
<br />
{| class="standard"<br />
|+Полезные переменные<br />
!Переменная<br />
!Описание<br />
|-<br />
|REPOCOP_TEST_STATEDIR<br />
|личная постоянная директория. Обычно $REPOCOP_STATEDIR/$REPOCOP_TEST_NAME<br />
|-<br />
|REPOCOP_STATEDIR<br />
|каталог, в котором хранятся личные постоянные директории тестов. Полезен для обращения к данным других тестов/коллекторов.<br />
|-<br />
|REPOCOP_TEST_TMPDIR<br />
|личная временная директория.<br />
|-<br />
|REPOCOP_TEST_NAME<br />
|<testname><br />
|-<br />
|REPOCOP_TEST_DBDIR<br />
|каталог с базами данных SQLite установленных коллекторов.<br />
|-<br />
|REPOCOP_TEST_DB<br />
|личная база данных SQLite теста или коллектора.<br />
|}<br />
<br />
В переменной REPOCOP_TEST_STATEDIR тесту передаётся его личная постоянная директория,<br />
чтобы он мог хранить в ней свое состояние как между вызовами <testname>/test так и между<br />
вызовами repocop-run, а в переменной REPOCOP_TEST_TMPDIR тесту передается его личная<br />
временная директория, которая сохраняется между вызовами <testname>/test и в конце<br />
гарантированно удаляется силами repocop-run.<br />
<br />
Тест общего вида может быть одновременно и коллектором, и постпроцессором,<br />
однако удобно, когда эти задачи разнесены в отдельные пакеты.<br />
<br />
==== Коллекторы ====<br />
<br />
Коллектор отличается от теста тем, что он никогда не вызывает <tt>repocop-test-*</tt>, и, следовательно,<br />
единственным результатом работы коллектора является создание базы данных.<br />
Также, для упаковки коллекторов предусмотрены каталоги<br />
{| class="standard"<br />
!Каталог<br />
!Описание<br />
|-<br />
|%_datadir/repocop/pkgcollectors/%testname/*<br />
|коллектор бинарных пакетов<br />
|-<br />
|%_libdir/repocop/pkgcollectors/%testname/*<br />
|коллектор бинарных пакетов<br />
|-<br />
|%_datadir/repocop/srccollectors/%testname/*<br />
|коллектор исходных пакетов<br />
|-<br />
|%_libdir/repocop/srccollectors/%testname/*<br />
|коллектор исходных пакетов<br />
|}<br />
<br />
а для тестов -<br />
{| class="standard"<br />
!Каталог<br />
!Описание<br />
|-<br />
|%_datadir/repocop/pkgtests/%testname/*<br />
|тест бинарных пакетов<br />
|-<br />
|%_libdir/repocop/pkgtests/%testname/*<br />
|тест бинарных пакетов<br />
|-<br />
|%_datadir/repocop/srctests/%testname/*<br />
|тест исходных пакетов<br />
|-<br />
|%_libdir/repocop/srctests/%testname/*<br />
|тест исходных пакетов<br />
|}<br />
<br />
===== Инициализация коллектора =====<br />
<br />
Рекомендуемый формат хранения базы данных, собираемой коллектором — файл SQLite с именем <tt><testname>.db</tt>,<br />
расположенный в REPOCOP_TEST_DBDIR. repocop в значительной мере упрощает инициализацию баз данных такого<br />
вида. При наличии файла <tt><testname>/init.sql.x</tt> (инициализация схемы БД под SQLite. x — версия схемы.) repocop<br />
проверяет, есть ли уже файл REPOCOP_TEST_DBDIR/<testname>.db и при необходимости создаёт её из указанной схемы.<br />
<br />
Если файл базы уже есть, то repocop запрашивает её версию командой «PRAGMA user_version». Если эта версия и число x<br />
совпадают, на этом инициализация заканчивается. Если текущая версия больше х, то происходит аварийный останов.<br />
Если текущая версия меньше х, то ищутся скрипты <tt><testname>/upgrade.sql.Y</tt>, где Y от currrent version+1 до x, и<br />
последовательно выполняются. Если найден скрипт <tt><testname>/upgrade</tt>, то он тоже выполняется.<br />
Если же скриптов обновления не найдено, то старая база удаляется. Также, если это тест, то его результаты тоже удаляются.<br />
repocop автоматически помечает базу версией x и при апгрейде, и при созданиии.<br />
<br />
Альтернативно, коллектор может вести свою базу в REPOCOP_TEST_STATEDIR в каком угодно формате.<br />
В этом случае для инициализации предусмотрен скрипт <tt><testname>/init</tt>.<br />
<br />
===== Обработка коллектором пакетов =====<br />
<br />
Обработка коллектором пакетов производится через вызовы <tt><testname>/test</tt> полностью аналогично тестам<br />
без состояния. Единственное отличие в том, что коллектор использует переменную окружения REPOCOP_PKG_KEY<br />
— внутренний id пакета в базах repocop. Коллектор не должен изобретать свои собственные идентификаторы пакета,<br />
а должен сохранять всю собранную информацию с этим REPOCOP_PKG_KEY.<br />
<br />
===== Завершение работы коллектора =====<br />
<br />
Если после работы коллектора остался какой-то мусор, его можно удалить в скрипте <tt><testname>/done</tt>.<br />
<br />
===== Уход за базой данных коллектора =====<br />
<br />
Со временем БД коллектора накапливает устаревшие записи о пакетах, которых больше нет в репозитории.<br />
Если коллектор хранит данные в базе вида REPOCOP_TEST_DBDIR/<testname>.db, то утилиты repocop-purge-*<br />
удалят из всех таблиц, содержащих колонку PKGID (название заглавными буквами) строки, соответствующие<br />
устаревшим pkgid. (pkgid — это то, что передается коллектору в переменной окружения REPOCOP_PKG_KEY).<br />
После этого дополнительно вызывается SQL скрипт <tt><testname>/purge.sql</tt>, если он существует.<br />
<br />
Если же коллектор использует своё собственное хранилище, для удаления устаревших записей из собственного<br />
кеша теста он должен предоставить скрипт <tt><testname>/purge</tt>.<br />
Утилиты repocop-purge-* вызовут этот скрипт автоматически. В качестве аргумента передается одна <br />
из опций <tt>--except</tt> либо <tt>--given</tt>, с тем же значением, что и в утилитах repocop-purge-*,<br />
а на stdin будет подан список pkgid, по одному pkgid на строку.<br />
<br />
==== Тесты-постпроцессоры ====<br />
<br />
Постпроцессор — это тест, который '''не''' тестирует отдельные пакеты, а использует готовые базы данных,<br />
собранные коллекторами. Такой тест состоит из единственного скрипта <tt><testname>/posttest</tt>.<br />
Допускается, что тест-постпроцессор может пометить каким-либо статусом только часть пакетов из присутствующих в базе.<br />
У остальных пакетов по умолчанию для этого теста будет статус skip.<br />
Поскольку при вызове <tt>repocop-test-*</tt> отсутствует естественный контекст (текущий пакет), то постпроцессор должен явно указывать пакет, которому присваивается статус. Для этого утилитам <tt>repocop-test-*</tt> передаётся опция <tt>-k|--key <pkgid></tt>, где <pkgid> в своё время был получен соответствующим коллектором через переменную окружения REPOCOP_PKG_KEY и сохранён им в своей базе.<br />
<br />
Пример простого теста-постпроцессора:<br />
<source lang="bash"><br />
#!/bin/sh <br />
sqlite3 "$REPOCOP_TEST_DBDIR/altlinux-alternatives.db" <<EOSQL<br />
.mode tabs<br />
.output $REPOCOP_TEST_TMPDIR/warn<br />
select distinct pkgid from altlinux_alternatives where altisxml>0;<br />
.output $REPOCOP_TEST_TMPDIR/ok<br />
select distinct pkgid from altlinux_alternatives where altisxml=0;<br />
EOSQL<br />
for i in `cat $REPOCOP_TEST_TMPDIR/warn`; do repocop-test-warn -k $i "xml format of alternatives is obsolete"; done<br />
for i in `cat $REPOCOP_TEST_TMPDIR/ok`; do repocop-test-ok -k $i; done<br />
rm $REPOCOP_TEST_TMPDIR/*<br />
</source><br />
<br />
==== Тесты пакетов с исходниками ====<br />
<br />
Аналогичны тестам бинарных пакетов за исключением того, что<br />
они устанавливаются в <tt>%_datadir/repocop/srctests/</tt>.<br />
Тестам передается в переменной<br />
* REPOCOP_PKG — полный путь к src.rpm пакету.<br />
* REPOCOP_PKG_ROOT — директория, в которую распаковано содержимое пакета.<br />
(для пакетов с исходниками по умолчанию распаковывается только spec-файл.<br />
содержимомое src.rpm — нужно ли это будет кому-то?)<br />
Дополнительно в переменной REPOCOP_PKG_SPECFILE передаётся полный путь к спек-файлу.<br />
также доступны:<br />
* REPOCOP_PKG_NAME<br />
* REPOCOP_PKG_VERSION<br />
* REPOCOP_PKG_RELEASE<br />
* REPOCOP_PKG_EPOCH<br />
и т. д., полностью аналогично тестам бинарных пакетов.<br />
<br />
пример простейшего теста.<br />
<source lang="bash"><br />
if OUTPUT=`rpmquery -p --requires $REPOCOP_PKG | egrep '(xorg-x11-devel|XFree86-devel)'`; then <br />
exec repocop-test-warn "Please, refresh your BuildRequires: using buildreq." \<br />
" The following obsolete dependencies blow up the build:" $OUTPUT<br />
else <br />
exec repocop-test-skip<br />
fi<br />
</source><br />
<br />
=== Исходный код ===<br />
<br />
Можно получить в [http://sisyphus.ru/find.shtml?request=repocop Sisyphus] и [http://git.altlinux.org/people/viy/packages/?p=repocop.git;a=summary git].</div>195.160.222.83https://www.altlinux.org/index.php?title=Info_Policy&diff=12054Info Policy2009-08-25T16:08:10Z<p>195.160.222.83: </p>
<hr />
<div>{{span|font-size: 180%|}}<br />
{{DraftPolicy<br />
|responsible=Igor Vlasenko<br />
}}<br />
<br />
== Полиси по упаковке Info файлов ==<br />
<br />
<pre><br />
В новой сборке пакета texinfo (точнее говоря, info-install) реализован<br />
файлтриггер, который теперь следит за тем, чтобы info index был всегда<br />
в актуальном состоянии.<br />
Мантейнерам спек-файлов больше не нужно следить за корректностью вызовов<br />
%install_info, %uninstall_info и %__install_info.<br />
Более того, теперь лучше все такие устаревшие вызовы из спек-файлов убрать.<br />
Для напоминания я расставил вывод предупреждений как на стадии вычисления<br />
устаревших макросов, так и в самих вызываемых утилитах.<br />
<br />
-- <br />
ldv<br />
<br />
<br />
> > Так же по новой схеме важно, чтобы у info файлов были заполнены<br />
> > INFO-DIR-SECTION и<br />
> > START-INFO-DIR-ENTRY.<br />
> > <br />
> > У нас нашелся всего один пакет без INFO-DIR-SECTION с явными <br />
> > --entry= --section=,<br />
> > ./ucblogo-6.0-alt1.src.spec:/sbin/install-info %_infodir/ucblogo.info<br />
+--entry="* UCBLogo: (ucblogo). Berkeley Logo User Manual."<br />
+--section="Programming Languages" %_infodir/dir 2>/dev/null || :<br />
<br />
Все прямые и косвенные вызовы install-info из спек-файлов теперь<br />
игнорируются.<br />
<br />
> Правильно ли я понимаю, что теперь, чтобы <br />
> избежать замусоривания %_infodir/dir, нам надо запретить<br />
> такие фокусы с --section= и --entry=",<br />
> и вместо этого явно патчить .info файлы, тобы<br />
> корректные INFO-DIR-SECTION и START-INFO-DIR-ENTRY<br />
> они носили с собой внутри?<br />
<br />
Да, только если есть texinfo-исходники (.texi) <br />
то патчить лучше texinfo-файлы.<br />
<br />
см.<br />
$ info texinfo 'Installing Dir Entries'<br />
<br />
Пример патча:<br />
----------------------------<br />
--- edb.texi 2009-08-25 15:51:51 +0000<br />
+++ edb.texi 2009-08-25 15:54:13 +0000<br />
@@ -7,6 +7,11 @@<br />
<br />
@syncodeindex tp cp<br />
<br />
+@dircategory Emacs<br />
+@direntry<br />
+ * EDB: (edb). The Emacs Database<br />
+@end direntry<br />
+<br />
@include version.texi<br />
<br />
@titlepage<br />
----------------------------<br />
<br />
> > И получается, по хорошему еще нужна проверка<br />
> > brp-verify-info на наличие INFO-DIR-SECTION и START-INFO-DIR-ENTRY.<br />
<br />
rpm-build-4.0.4-alt98.10 уже проверяет info-файлы.<br />
По умолчанию наличие неправильных info-файлов является ошибкой.<br />
Изменить умолчание можно с помощью<br />
%set_verify_info_method relaxed<br />
<br />
> > Тогда надо подправить update-info-dir,<br />
> > чтобы он был совместим с %_xemacs_installinfo.<br />
> > Иначе сейчас это ломает справку xemacs.<br />
<br />
texinfo-4.13-alt4 уже обучен обрабатывать каждый каталог в /usr/share/info<br />
отдельно.<br />
</pre></div>195.160.222.83https://www.altlinux.org/index.php?title=Info_Policy&diff=11602Info Policy2009-07-05T12:22:17Z<p>195.160.222.83: /* Полиси по упаковке Info файлов */</p>
<hr />
<div>{{span|font-size: 180%|}}<br />
{{DraftPolicy<br />
|responsible=Igor Vlasenko<br />
}}<br />
<br />
== Полиси по упаковке Info файлов ==<br />
<br />
<pre><br />
В новой сборке пакета texinfo (точнее говоря, info-install) реализован<br />
файлтриггер, который теперь следит за тем, чтобы info index был всегда<br />
в актуальном состоянии.<br />
Мантейнерам спек-файлов больше не нужно следить за корректностью вызовов<br />
%install_info, %uninstall_info и %__install_info.<br />
Более того, теперь лучше все такие устаревшие вызовы из спек-файлов убрать.<br />
Для напоминания я расставил вывод предупреждений как на стадии вычисления<br />
устаревших макросов, так и в самих вызываемых утилитах.<br />
<br />
-- <br />
ldv<br />
<br />
<br />
> > Так же по новой схеме важно, чтобы у info файлов были заполнены<br />
> > INFO-DIR-SECTION и<br />
> > START-INFO-DIR-ENTRY.<br />
> > <br />
> > У нас нашелся всего один пакет без INFO-DIR-SECTION с явными <br />
> > --entry= --section=,<br />
> > ./ucblogo-6.0-alt1.src.spec:/sbin/install-info %_infodir/ucblogo.info<br />
+--entry="* UCBLogo: (ucblogo). Berkeley Logo User Manual."<br />
+--section="Programming Languages" %_infodir/dir 2>/dev/null || :<br />
<br />
Все прямые и косвенные вызовы install-info из спек-файлов теперь<br />
игнорируются.<br />
<br />
> Правильно ли я понимаю, что теперь, чтобы <br />
> избежать замусоривания %_infodir/dir, нам надо запретить<br />
> такие фокусы с --section= и --entry=",<br />
> и вместо этого явно патчить .info файлы, тобы<br />
> корректные INFO-DIR-SECTION и START-INFO-DIR-ENTRY<br />
> они носили с собой внутри?<br />
<br />
Да, только патчить надо texinfo-файлы.<br />
<br />
см.<br />
$ info texinfo 'Installing Dir Entries'<br />
<br />
> > И получается, по хорошему еще нужна проверка<br />
> > brp-verify-info на наличие INFO-DIR-SECTION и START-INFO-DIR-ENTRY.<br />
<br />
rpm-build-4.0.4-alt98.10 уже проверяет info-файлы.<br />
По умолчанию наличие неправильных info-файлов является ошибкой.<br />
Изменить умолчание можно с помощью<br />
%set_verify_info_method relaxed<br />
<br />
> > Тогда надо подправить update-info-dir,<br />
> > чтобы он был совместим с %_xemacs_installinfo.<br />
> > Иначе сейчас это ломает справку xemacs.<br />
<br />
texinfo-4.13-alt4 уже обучен обрабатывать каждый каталог в /usr/share/info<br />
отдельно.<br />
</pre></div>195.160.222.83https://www.altlinux.org/index.php?title=Info_Policy&diff=11216Info Policy2009-05-18T17:32:58Z<p>195.160.222.83: Создана новая страница размером {{span|font-size: 180%|}} {{DraftPolicy |responsible=Igor Vlasenko }} == Полиси по упаковке Info файлов == <pre> ...</p>
<hr />
<div>{{span|font-size: 180%|}}<br />
{{DraftPolicy<br />
|responsible=Igor Vlasenko<br />
}}<br />
<br />
== Полиси по упаковке Info файлов ==<br />
<br />
<pre><br />
В новой сборке пакета texinfo (точнее говоря, info-install) реализован<br />
файлтриггер, который теперь следит за тем, чтобы info index был всегда<br />
в актуальном состоянии.<br />
Мантейнерам спек-файлов больше не нужно следить за корректностью вызовов<br />
%install_info, %uninstall_info и %__install_info.<br />
Более того, теперь лучше все такие устаревшие вызовы из спек-файлов убрать.<br />
Для напоминания я расставил вывод предупреждений как на стадии вычисления<br />
устаревших макросов, так и в самих вызываемых утилитах.<br />
<br />
-- <br />
ldv<br />
<br />
<br />
> > Так же по новой схеме важно, чтобы у info файлов были заполнены<br />
> > INFO-DIR-SECTION и<br />
> > START-INFO-DIR-ENTRY.<br />
> > <br />
> > У нас нашелся всего один пакет без INFO-DIR-SECTION с явными <br />
> > --entry= --section=,<br />
> > ./ucblogo-6.0-alt1.src.spec:/sbin/install-info %_infodir/ucblogo.info<br />
+--entry="* UCBLogo: (ucblogo). Berkeley Logo User Manual."<br />
+--section="Programming Languages" %_infodir/dir 2>/dev/null || :<br />
<br />
Все прямые и косвенные вызовы install-info из спек-файлов теперь<br />
игнорируются.<br />
<br />
> Правильно ли я понимаю, что теперь, чтобы <br />
> избежать замусоривания %_infodir/dir, нам надо запретить<br />
> такие фокусы с --section= и --entry=",<br />
> и вместо этого явно патчить .info файлы, тобы<br />
> корректные INFO-DIR-SECTION и START-INFO-DIR-ENTRY<br />
> они носили с собой внутри?<br />
<br />
Да, только патчить надо texinfo-файлы.<br />
</pre></div>195.160.222.83https://www.altlinux.org/index.php?title=Mass_NMU&diff=10633Mass NMU2009-04-10T06:45:48Z<p>195.160.222.83: /* Пример */</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=viy@<br />
|discussion_link=http://lists.altlinux.org/pipermail/devel/2009-April/169093.html<br />
|discussion_since=10.04.2009<br />
}}<br />
'''Mass NMU''' (Non-Maintainer Upload) — массовое обновление чужих пакетов.<br />
<br />
== Общие соображения ==<br />
<br />
Данное полиси является дополнением к [[NMU]] полиси и описывает дополнительные процедуры, которых нужно придерживаться для проведения массового NMU.<br />
<br />
Для точечного NMU на пакет foobar у делающего это NMU достаточно времени чтобы обсудить это с мейнтейнером.<br />
<br />
Однако если пакетов много, и мейнтейнеров много, проведение массового NMU как набора точечных NMU становится крайне затруднительным.<br />
<br />
Вместо этого MassNMU полиси описывает процедуры, с помощью которых можно обращаться ко всем мейнтейнерам вместе, а не к каждому по отдельности.<br />
При этом при необходимости администратор репозитория может выдать NMU вместо отсутствующих или не высказавшихся мейнтейнеров.<br />
<br />
Чтобы при проведении массовых NMU не было злоупотреблений, изменения, вносимые в пакеты при массовых NMU, должны быть бесспорными, основанными на общепринятой традиции или действующих полиси.<br />
<br />
То есть надо подчеркнуть, что в массовых NMU, общий принцип которых не вызывает разногласий (например, основан на полиси) мейнтейнер считается по умолчанию (поскольку общий принцип не вызывает разногласий) согласным на NMU, а если не согласен — должен высказать явно.<br />
<br />
== Правила подготовки массовых NMU ==<br />
<br />
* Алгоритм и сгенерированные патчи выносятся на публичное обсуждение.<br />
* Если алгоритм основан на полиси, достаточно явно сослаться на полиси.<br />
* Иначе, алгоритм должен быть основан на полиси (драфте) или ещё как-либо документирован, пройти обсуждение в devel@,<br />
<br />
Если в {{lists|devel}} предложенные изменения не вызывают возражений, либо возражения снимаются голосованием или отводом/исправлением, то алгоритм и патчи считаются принятыми сообществом.<br />
<br />
Срок обсуждения — от 2-х недель.<br />
<br />
=== Пример ===<br />
<br />
Т.е. - если я, скажем, завтра напишу робота, который.. ну допустим <br />
исправляет зависимости у всех KDE'шных пакетов, отправляя каждый из них <br />
на пересборку с определённым патчем на спек.<br />
Каким образом должен выглядеть процесс такого массового NMU ? <br />
<br />
# написать драфт полиси, которое стремится воплотить в жизнь робот.<br />
# анонсировать патчи.<br />
# завести страницу на wiki, на которой желающие будут добавлять свои пакеты в список пакетов, не берущих участия в NMU.<br />
<br />
Если<br />
# сообщество приняло драфт как полиси.<br />
# истек срок (2-3 недели?)<br />
то<br />
# Наступает deadline, кто не успел заявить отвод nmu на свои пакеты, тот опоздал.<br />
# Автор робота получает право NMU на все заявленные им пакеты, кроме тех, по которым заявлен отвод.<br />
<br />
Должен ли предпринимать какие-то шаги администратор репозитария ?<br />
<br />
Дать NMU от имени промолчавших мейнтейнеров.<br />
<br />
== Ссылки ==<br />
* [[NMU]]</div>195.160.222.83