https://www.altlinux.org/api.php?action=feedcontributions&user=213.228.89.113&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-29T10:43:45ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=Repocop&diff=8877Repocop2009-02-03T19:14:59Z<p>213.228.89.113: fixed typo</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
[[Категория:Devel]]<br />
<!--MovedFromFreesourceInfo|AltLinux/Sisyphus/Tools/Repocop--><br />
{|<br />
|-<br />
|<br />
[[Изображение:Robocop-12inch-5-01.jpg]]<br />
|<br />
[http://absurdopedia.wikia.com/wiki/%D0%9E%D0%B3%D1%80%D0%BE%D0%BC%D0%BD%D1%8B%D0%B9_%D0%B1%D0%BE%D0%B5%D0%B2%D0%BE%D0%B9_%D1%80%D0%BE%D0%B1%D0%BE%D1%82 Малый огромный боевой робот], созданный [http://absurdopedia.wikia.com/wiki/%D0%91%D0%B5%D0%B7%D1%83%D0%BC%D0%BD%D1%8B%D0%B5_%D1%83%D1%87%D0%B5%D0%BD%D1%8B%D0%B5 безумными учёными]<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 />
Например, для майнтейнера 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 />
|}<br />
<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 />
: <pre>repocop-run ~/hasher/repo/*/RPMS.hasher/*.rpm</pre><br />
* Пример запуска repocop для тестирования репозитория:<br />
: <pre>repocop-run /var/ftp/pub/Linux/ALT/Sisyphus/files/{noarch,i586}/RPMS</pre><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>/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>/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 />
<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_CACHEDIR<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_CACHEDIR тесту передаётся его личная постоянная директория,<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_CACHEDIR в каком угодно формате.<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>/done</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>213.228.89.113https://www.altlinux.org/index.php?title=Books:Altlibrary&diff=8876Books:Altlibrary2009-02-03T19:12:21Z<p>213.228.89.113: /* Выходные данные */</p>
<hr />
<div>== Серия «Библиотека ALT Linux» ==<br />
<br />
'''Cерия книг о свободном программном обеспечении и самых разных областях его применения. К каждой книге прилагается специально сформированный тематический дистрибутив ALT Linux или Live CD, построенный исключительно из свободного ПО.'''<br />
<br />
В XXI веке в области информационных технологий уже нельзя не замечать или игнорировать свободное ПО: это и общественное движение, и особый процесс разработки, в котором возникают и активно развиваются многие технологии и инновационные идеи. Но если смотреть не глазом аналитика с высоты обзора рынка, а глазами обычного человека с точки зрения повседневной жизни, то в свободном ПО явно видно выражение естественных для человека стремлений общаться, делиться и помогать.<br />
<br />
Материалы всех публикуемых в серии книг также распространяются под свободными лицензиями.<br />
<br />
<gallery caption="В серии вышли"><br />
Изображение:Openoffice_cover.png|[[Books:Openoffice|OpenOffice.org: Теория и практика]]<br />
Изображение:Scilab_cover.png|[[Books:Scilab|Scilab: Решение инженерных и математических задач]]<br />
Изображение:Insideout_cover.png|[[Books:Insideout|ALT Linux снаружи / ALT Linux изнутри]]<br />
</gallery><br />
<br />
=== Темы серии ===<br />
<br />
* Хобби — свободное ПО для дома, как увлечение и для увлечений<br />
* Специальность — свободное ПО для профессионалов: музыкантов, учёных, медиков<br />
* Курс — преподавателю и студенту: курсы и учебные материалы на основе свободного ПО<br />
* Сообщество — свободное ПО в общественной жизни и в государстве <br />
<br />
=== Выходные данные ===<br />
<br />
{|class="standard"<br />
|Редактор серии<br />
|[[Участник:KirillMaslinsky|Кирилл Маслинский]], пишите kirill@altlinux.ru <br />
|-<br />
|Издатели<br />
|компания [http://altlinux.ru ALT Linux]; издательство [http://www.lbz.ru БИНОМ. Лаборатория знаний]; издательский дом [http://dmk-press.ru ДМК-пресс]<br />
|-<br />
|Условия публикации<br />
|в серии публикуются ''только'' тексты, [[Books:AuthorsFAQ|распространяемые под свободными лицензиями]]<br />
|}<br />
<br />
{{DEFAULTSORT:{{PAGENAME}}}}<br />
[[Категория:Библиотека ALT Linux]]</div>213.228.89.113https://www.altlinux.org/index.php?title=Git&diff=8059Git2009-01-01T08:17:40Z<p>213.228.89.113: /* workflow */ fix path</p>
<hr />
<div>{{DISPLAYTITLE:git}}<br />
{{Stub}}<br />
{{MovedFromFreesourceInfo|AltLinux/Sisyphus/devel/git}}<br />
== Руководства ==<br />
<br />
* [[Краткое руководство по сборке с gear]]<br />
* [[Git.alt|Руководство по git.alt]]<br />
<br />
== Всё о GIT, со слов ldv ==<br />
<br />
''Здесь на самом деле не про git per se, а про git применительно к ALT Linux и git.alt; в качестве введения в git см., например, [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT].''<br />
<br />
''Некое подобие QuickStart по git@ALT для присматривающихся участников team -- [[git/start|здесь]].''<br />
<br />
<div style="display: inline; color: red;">NB: эту страницу (а также [[gear|gear]], [[gear/kis|gear/kis]], [[gear/geartags|gear/geartags]], [[gear/ImportUpstreamVBranch|gear/ImportUpstreamVBranch]], [[gear/ImportSeparateUpstream|gear/ImportSeparateUpstream]], [[git/recommit|git/recommit]], [[git/gitnotes|git/gitnotes]], [[git/gitincompact|git/gitincompact]], [[git/SomeDestReposViaBranches|git/SomeDestReposViaBranches]], [[git/MergingBranches|git/MergingBranches]], [[git/BranchInGit|git/BranchInGit]]) надо творчески раскромсать на:</div><br />
* Введение в git + ссылки<br />
* [[Git.alt|Руководство по git.alt]]<br />
* [[Руководство по gear]]<br />
* [[Справочник по git.alt]]<br />
* Справочник по gear<br />
<br />
__TOC__<br />
<br />
=== GEAR ===<br />
<br />
В апреле 2006 года идея хранить исходный код пакетов в git-репозитории была реализована с помощью утилиты, которая 27-го апреля получила имя [[gear|gear]]. Напомню вкратце:<br />
<br />
Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также минимизации трафика и места на диске для хранения архива репозитория за длительный срок. Идея <tt>gear</tt> заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно <tt>git</tt>+<tt>sed</tt>) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с [[hasher]], который был задуман как средство собирать пакеты из произвольных srpm-пакетов.<br />
<br />
За время, прошедшее с конца апреля, многие из вас успели освоиться с <tt>gear</tt>, появилась базовая документация, семейство вспомогательных утилит и опыт эксплуатации. Поэтому весьма вероятно, что те из вас, кому только предстоит осваивать gear, пройдут этот путь гораздо легче и быстрее чем я. :) Например, одна только утилита <tt>gear-srpmimport</tt> позволяет на начальном этапе вообще не интересоваться синтаксисом файла <tt>.gear-rules</tt>.<br />
<br />
На всякий случай рекомендую установить/обновить пакет <tt>gear</tt>, а также освежить в своей памяти содержимое файлов <tt>/usr/share/doc/gear-1.4.0/QUICKSTART.ru.html</tt> и <tt>/usr/share/doc/git-1.5.5.3/tutorial.html</tt><br />
<br />
=== Структура репозитория ===<br />
<br />
Как уже было сказано, <tt>gear</tt> не накладывает ограничений на внутреннюю организацию git-репозитория (не считая файла с правилами). Тем не менее, у меня есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения пакетов:<br />
<br />
* Одна сущность — один репозиторий.<br />
*: Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок. Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий git больше подходит для работы с такими репозиториями.<br />
*:: '''Отрицательная сторона''': несколько сложнее делать «push» и «pull» в случае, когда репозиториев, которые надо обработать, много. Впрочем, push/pull в цикле выручает.<br />
* Несжатый исходный код.<br />
*: Сжатый разными архиваторами исходный код (как правило это tarball’ы) лучше хранить в git-репозитории в несжатом виде. Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (<tt>git-diff</tt>). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, заметно более эффективен на несжатых данных.<br />
*:: '''Отрицательная сторона''': поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.<br />
* Распакованный исходный код.<br />
*: Исходный код, запакованный tar/cpio/…, лучше хранить в git-репозитории в распакованном виде, по тем же причинам (заметно удобнее отслеживать изменения, существенно меньше трафик при обновлении).<br />
*:: '''Отрицательная сторона''': поскольку git из информации о владельце, правах доступа и дате модификации файлов хранит только исполняемость файлов, любой архив, созданный из репозитория, будет по этим параметрам отличаться от первозданного. Помимо потери нативности, изменение прав доступа и даты модификации может теоретически повлиять на результат сборки пакета. Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править.<br />
* Аккуратный changelog.<br />
*: В changelog релизного commit’а стоит включать соответствующий текст из changelog’а пакета, как это делают утилиты <tt>gear-commit</tt> (обёртка к <tt>git-commit</tt>, специально предназначенная для этих целей) и <tt>gear-srpmimport</tt>. В результате можно будет получить представление об изменениях в пакете, не заглядывая в spec-файл самого пакета.<br />
<br />
=== Инструкция по эксплуатации git.altlinux.org ===<br />
<br />
Для преодоления барьеров вида «админ закрыл наружу всё и оставил только прокси» ssh на git.altlinux.org доступен также и на порту 443, что можно [[fsi:SSHFirewall|использовать]].<br />
<br />
По всем вопросам, связанным с этой частью инструкции, пишите на join@.<br />
<br />
Клонировать к себе на компьютер свой репозиторий с git.altlinux.org:<br />
<br />
$ git-clone git.alt:packages/vitmp.git<br />
remote: Generating pack...<br />
remote: Done counting 12 objects.<br />
remote: Deltifying 12 objects.<br />
remote: 100% (12/12) done<br />
remote: Total 12, written 12 (delta 2), reused 12 (delta 2)<br />
<br />
Клонировать к себе на компьютер чужой репозиторий с git.altlinux.org:<br />
$ git-clone git.alt:/people/ldv/packages/vitmp.git<br />
<br />
Залить на git.alt свой ранее созданный git-репозиторий:<br />
cd ~/package<br />
$ git push --all git.alt:packages/package.git<br />
<br />
Представим, что некий foo сделал какие-либо изменения для нашего пакета bar в бранче bar-bugfree и выложил их на git.alt.<br />
Узнаем, как называется его этот бранч:<br />
$ git ls-remote git.alt:/people/foo/packages/bar.git<br />
<br />
Далее зафетчим этот бранч к нам с одноименным названием:<br />
<br />
$ git-fetch git.alt:/people/foo/packages/bar.git bar-bugfree:bar-bugfree<br />
<br />
Дальше работаем с ним как хотим ;)<br />
<br />
Удалить бранч на git.alt (задав пустое имя локального бранча):<br />
$ git push ... :branch<br />
<br />
Копирование файлов из одного бранча в другой:<br />
$ git-archive --format=tar --prefix=directory-branchXXX branchXXX:directory | tar xf -<br />
и устаревший способ:<br />
$ git-tar-tree branchXXX:directory directory-branchXXX | tar xf -<br />
<br />
== Ответы на часто забываемые вопросы ==<br />
<br />
=== «Как найти майнтейнера?» ===<br />
# [http://alt3.linux.kiev.ua/srpm/Sisyphus/spt/git http://alt3.linux.kiev.ua/srpm/Sisyphus/spt/git] (с датами и ссылками)<br />
# [http://git.altlinux.org/people-packages-list http://git.altlinux.org/people-packages-list]<br />
# см. ниже:<br />
{{Начало цитаты|источник=[http://lists.altlinux.org/pipermail/devel/2007-March/043158.html ldv@]}}<br />
> Слить сорцы из git'а, сделать патч и отправить автору (да, в мире существуют <br /><br />
> другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того <br /><br />
> типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual <br /><br />
> mantainers, которых почти всё устраивает, но иногда хочется написать патчик и <br /><br />
> отправить обратно.<br />
<br />
В принципе, даже той информации, которая есть в бинарном пакете сейчас,<br />
уже достаточно для casual mantainers:<br />
<br />
1. В установленном бинарном пакете есть %{SOURCERPM} (виден по rpmquery -i),<br />
из которого однозначно вычисляется имя исходного пакета.<br />
<br />
2. Далее, в установленном бинарном пакете есть %{CHANGELOGNAME} (виден по<br />
rpmquery --lastchange).<br />
<br />
3. По именам мантейнера (MAINT) и исходного пакета (PKG) можно с очень<br />
высокой вероятностью предположить, что если пакет был собран из<br />
git-репозитория, то этот репозиторий называется<br />
<nowiki>http://git.altlinux.org/people/MAINT/packages/?p=PKG.git</nowiki><br />
{{Конец цитаты}}<br />
<br />
=== Как вести пакет в git ===<br />
{{Начало цитаты|источник={{man|damir}}}}<br />
Посмотрите на http://git.altlinux.org/people/damir/packages/?p=liblazy.git;a=summary<br />
<br />
Там правда апстрим git-овый, но это сути не меняет.<br />
.gear-rules там состоит из одной строчки - вот такой:<br />
<br />
tar.bz2: @name@-@version@:.<br />
<br />
@name@ и @version@ берутся из спека. @name@ - это liblazy. а @version@ - это 0.1<br />
<br />
На ветке upstream присутствует тег liblazy-0.1. Поэтому апстримный<br />
тарбол будет браться из этого тега.<br />
<br />
При переезде на новую версию надо будет всего лишь:<br />
<br />
1. Поставить нужный тег на апстримной ветке (например liblazy-0.2). <br /><br />
2. Смержить этот тег в master с -s ours <br /><br />
3. Заменить в спеке версию с 0.1 на 0.2. <br /><br />
4. Выполнить gear-update-tag -ac <br /><br />
5. Дописать changelog<br />
{{Конец цитаты}}<br />
<br />
=== Как втащить пакет из Сизифа, если его нет на git.alt/people ===<br />
Пакет, который давно не собирался или заброшен, или его майнтейнер не пользуется git.alt, можно найти в [http://git.altlinux.org/archive/ архиве Сизифа]. Архив Сизифа содержит последние версии когда-либо собиравшихся в Сизиф пакетов (с историей) и доступен по <tt>ssh git.alt</tt> в каталоге <tt>/archive</tt>. Для удобства хранилища собраны в двухуровневое дерево (по первой букве), без различия майнтейнеров.<br />
<br />
Таким образом ''на сегодня'' <tt>git-clone git.alt:/archive/m/mkimage</tt> отдаст хранилище, соответствующее текущему пакету <tt>mkimage</tt> в Сизифе, кто бы его ни собрал на этот раз.<br />
<br />
=== workflow ===<br />
<br />
Совместная работа над пакетами в git строится по следующей схеме:<br />
<br />
[ user A ] [ user B ]<br />
| [repo A/X] |<br />
| | |<br />
| |----------+-->[repo B/X] -- B клонирует репозиторий A/X в свой B/X<br />
| | | |<br />
| | |------>| -- B работает над содержимым репозитория<br />
| | |------>|<br />
| | |------>| -- B решает, что результат ему нравится<br />
|<-----------------| | -- B оповещает A о том, что в B/X<br />
| | | | имеется что-то новое<br />
|-------+<-----------------| -- A добавляет (pull/push) содержимое<br />
| | | | B/X в A/X<br />
<br />
При дальнейшей работе сценарий повторяется, за исключением того, что B не клонирует репозиторий A/X, а подтягивает (pull) из него новые изменения.<br />
<br />
Как это реализуется на практике?<br />
<br />
Для поиска репозитория для клонирования используется команда <tt>find-package</tt>:<br />
$ ssh git.alt find-package bugzilla<br />
/people/vvk/packages/bugzilla.git 1168522087<br />
$<br />
Склонировать репозиторий можно с помощью команды <tt>clone</tt>:<br />
$ ssh git.alt clone /people/vvk/packages/bugzilla.git<br />
Initialized empty Git repository in /people/dottedmag/packages/bugzilla.git/<br />
$<br />
Эта команда создаст вашу копию репозитория ''на сервере git.alt''. Для работы с ним необходимо склонировать этот репозиторий на локальную машину:<br />
$ git clone ssh://git.alt/people/dottedmag/packages/bugzilla.git<br />
Initialized empty Git repository in /home/dottedmag/bugzilla/.git/<br />
....<br />
$<br />
С этим git-репозиторием можно работать как обычно: править, делать commit и так далее. Поскольку для склонированного репозитория создаётся remote с названием origin, то <tt>git-push</tt> тоже работает:<br />
$ git push<br />
...<br />
$<br />
Нотификации производятся вручную - почтой или через bugzilla. Аналога pull request из github или gitorious на <tt>git.alt</tt> пока что нет.<br />
<br />
Втягивание чужих изменений производится стандартными git-средствами: добавлением remote<br />
$ git remote add someuser ssh://git.alt/people/someuser/packages/bugzilla.git<br />
засасыванием изменений:<br />
$ git fetch someuser master<br />
наложением их:<br />
$ git merge someuser/master<br />
и отправкой в <tt>git.alt</tt>:<br />
$ git push<br />
<br />
== Удаление удалённных веток в git ==<br />
<br />
Если вы хотите удалить ветку из репозитория, располагающегося не на вашей машине - сделайте в него <tt>push</tt> из "никакоЙ" ветки:<br />
<br />
git push origin :no-longer-needed-branch<br />
<br />
Полная форма <tt>push</tt> выглядит так:<br />
git push <remote> <from>:<to><br />
<br />
Где <from> - ''откуда'' из локального репозитория, а <to> - ''куда'' в удалённый совершается push. Привычный вид<br />
git push <remote> <branch><br />
- лишь сокращение<br />
git push <remote> <branch>:<branch><br />
<br />
== Ссылки ==<br />
=== По-русски ===<br />
* [http://freesource.info/wiki/RuslanHihin/GitTutorial1 Учебник «Введение в git» (для версии 1.5.1 или более поздней версии]<br />
* [http://freesource.info/wiki/RuslanHihin/20povsedevnyxkomandgit 20 повседневных команд git]<br />
* [http://freesource.info/wiki/RuslanHihin/GitUserManual Главы из руководства пользователя git]<br />
* [http://los-t.livejournal.com/tag/git+guts git guts] (внутренности git)<br />
* [http://blog.tarantsov.com/2008/11/essential-git.html Введение в структуру хранилища git] (полезно для понимания происходящего)<br />
<br />
=== Вводные статьи ===<br />
* [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated])<br />
* [http://cworth.org/hgbook-git/tour/ A tour of git: the basics]<br />
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday Git] With 20 Commands Or So<br />
<br />
=== Официальная документация ===<br />
* [http://www.kernel.org/pub/software/scm/git/docs/user-manual.html Git User's Manual]<br />
* [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html tutorial] по 1.5+, в частности<br />
* [http://kernel.org/pub/software/scm/git/docs/howto/ Git Howtos]<br />
* [http://git.or.cz/gitwiki/ GitWiki]<br />
** [http://git.or.cz/gitwiki/GitDocumentation GitDocumentation]<br />
** [http://git.or.cz/gitwiki/QuickStart QuickStart]<br />
** [http://git.or.cz/gitwiki/IndexCommandQuickref IndexCommandQuickref]<br />
** [http://git.or.cz/gitwiki/GitTips GitTips]<br />
** [http://git.or.cz/gitwiki/GitFaq GitFaq]<br />
** [http://git.or.cz/gitwiki/GitWorkflows GitWorkflows]<br />
** [http://git.or.cz/gitwiki/ExampleScripts ExampleScripts]<br />
** [http://git.or.cz/gitwiki/Aliases Aliases]<br />
** [http://git.or.cz/gitwiki/GitGlossary GitGlossary]<br />
<br />
=== tips&tricks ===<br />
* [[git/recommit|Как переделать commit, в котором сразу же нашёлся ляп]]<br />
* [[git/MergingBranches|Как мержить бранчи]], поддерживая пакет с N пересекающимися патчами<br />
* [[git/gitincompact|Как установить git в Compact 3.0]]<br />
* [http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Zack Rusin: Git cheat sheet] ([http://www.samlown.com/uploads/documents/git-cheat-sheet-a4.pdf A4])<br />
* [http://tomayko.com/writings/the-thing-about-git The Thing About Git]<br />
* [http://article.gmane.org/gmane.comp.version-control.git/31625 Branching and merging with git]<br />
<br />
=== Разное ===<br />
* [http://github.com/guides GitHub: Git Guides]<br />
* [http://www.gitcasts.com/ GitCasts]<br />
* [http://gitfu.wordpress.com/ git-fu]<br />
* [http://lwn.net/Articles/245678/ Линкдамп] по документации git<br />
* [http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html Git Magic]<br />
* [http://linux.yyz.us/git-howto.html Kernel Hackers' Guide to git]<br />
* [http://www.opensolaris.org/os/community/tools/scm/git-report-final.txt Обзор git] для сообщества OpenSolaris<br />
* [http://www.sourcemage.org/Git_Guide Git Guide - SourceMage Wiki]<br />
* [http://www.infoq.com/articles/dvcs-guide Distributed Version Control Systems: A Not-So-Quick Guide Through]<br />
* [http://versioncontrolblog.com/ Version Control Blog]<br />
<br />
<br />
{{Category navigation|title=git|category=git|sortkey=*}}</div>213.228.89.113https://www.altlinux.org/index.php?title=%D0%9A%D0%B0%D0%BA_%D1%81%D0%B4%D0%B5%D0%BB%D0%B0%D1%82%D1%8C_%D1%81%D0%B0%D0%BC%D1%8B%D0%B9_%D0%BF%D0%BE%D0%BF%D1%83%D0%BB%D1%8F%D1%80%D0%BD%D1%8B%D0%B9_%D0%B4%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%3F&diff=5685Как сделать самый популярный дистрибутив?2008-11-09T10:03:48Z<p>213.228.89.113: Исправлена опечатка</p>
<hr />
<div>Напишите, что может сделать дистрибутив Linux самым популярным продуктом для пользователя персонального компьютера, администратора сервера, разработчика.<br />
<br />
См. также [[Планы на ALT Linux 5.0 Desktop]].<br />
<br />
* Поддержка всего оборудования из коробки<br />
* Полная локализация<br />
* Работа таких популярных приложений, как 1С, Консультант+, Гарант и т.п.<br />
* Поддержка NTFS, mp3, шрифтов и кодеков из коробки (а разве этого нет?)<br />
* Прозрачная интеграция wine<br />
* Считаем что оборудование будет работать из коробки - Wi-Fi и все такое, Compiz-ы всякие на Intel/ATi и прочие свистелки, - я бы смотрел на креативный дизайн, начиная от выбора операционной системы и заканчивая moodin-темой и фоновыми рисунками + цветовой гаммой + тема-dekorator<br />
* Самое главное для админа сети из трех и более компьютеров - развертывание доменной структуры из коробки в несколько кликов. Единый центр авторизации с прозрачной, стандартной привязкой доп. служб (samba/nfs, apache, squid, postfix,..) и единым интерфейсом (alterator?),.. Самое близкое к идеалу ТЗ (из того, что я читал на эту тему) здесь: http://freesource.info/wiki/TZ/ServerIntegracii?v=7bv&<br />
* Включение софта необходимого людям различных специальностей: физики, математики, химики, программисты и т.д. Каждый должен найтив нем инструменты для решения своих задач, причем лучшие (в этой области) инструменты.<br />
* Установка системы из livecd<br />
<br />
== Пожелания пользователей ==<br />
(''взято с [http://sibskull.livejournal.com/36854.html?thread=312054#t312054 http://sibskull.livejournal.com/36854.html?thread=312054#t312054]'')<br />
<br />
* Удобный и функциональный центр управления системой (как Mandriva Control Center)<br />
* Проигрывание любых мультимедийных форматов из коробки<br />
* репозиторий с бэкпортами, активно поддерживающийся и регулярно обновляющийся. Не полгода, пока не выйдет новая версия дистрибутива, а года два<br />
* стабильный и отлаженный дистрибутив. Чтобы после установки всё работало нормально и не было проблем в самых неожиданных местах<br />
* дистрибутив должен быть современный, но не bleeding edge<br />
* у дистрибутива должна быть максимально возможная локализация</div>213.228.89.113