/*
Господа и Дамы,
мы продолжаем крайне непопулярную серию заметок, посвящённых openSUSE Build Service. ежели Вам оно не надо - самое время заняться чем-то другим. а мы продолжим, с Божьей помощью...
Боже, Царя храни!
Сильный, державный,
Царствуй на славу нам;
Царствуй на страх врагам,
Царь православный!
Боже, Царя храни!
/1833, Василий Андреевич Жуковский/
поводом к этим зарисовкам послужил трэд забавного форума, где раком встал очевидный недостаток информации как таковой. трэд в принципе "ни-о-чём", но кое-что можно вытянуть и оттуда. сразу же оговорюсь - учите английский и не надейтесь на локализацию АКТУАЛЬНОЙ документации. то, что присутствует на "нащих" официальных сайтах (примерчик), зачастую вызывает желание громко расхохотаться от умиления (на самом деле привыкайте рыть доки самостоятельно).
итак, давайте прикинем, что входит в "краткий перечень инструкций по работе с OBS" (дополнения приветствуются):
* вводная в OBS
* инструкция, как компилять для разных дистрибутивов
* ликбез, краткая версия
* ликбез, версия для любознательных
* Tips and Tricks - эт уже пойдёт веселее
* базовые приёмы работы из командной строки
вроде как всё, но это только затравка. есть отдельные документы, представляющие определённую ценность (по крайней мере на первых этапах). вы можете "стоять на своём" (любимая пытка Бормана кстати), но таки приведу списочек:
* статейка о махровом коллаборационизме или как работать над проектом сообща
* "чёрная метка" одноглазого Сильвера - обязательно к ознакомлению. если Вам это не подходит - лучше приложите свои силы в Пакман-е
* проверки rpmlint
* правила для пакетов с shared libraries. по хорошему в дистрибутиве не должно быть статически слинкованных библилтек/бинарей, поэтому если вы собрались "упаковать" какую-нить завалящую либку, то обязательно прочтите это.
* глобальная дока "по всему", что касается специфики создания пакетов в openSUSE - желательно, чтобы вы хоть краем глаза пробежались по содержанию.
* работа с модулями ядра. если кто недопёр о чём речь, то шаблоны Code9 и Code10 выкладываю отдельно. также выкладываю линк на дивный скриптец - extract_kABI. коли вы ни ухом ни рылом ап чём речь, то замечу, что kABI - это аббревиатура от "kernel Application Binary Interface". дивная штуковина. иногда бывают чудеса и енто самое kABI не меняется при смене версии ядра для какого-то модуля, что позволяет ему (модулю) сукесфули функционировать на благо Царя и Отечества без перекомпиляции. в такие моменты понимаешь, что оргазм - ничто, по сравнению с ... таким работающим модулем...
для начала вроде должно хватить. поскольку комментариев на первую заметку не было, то сделал вывод, что тема нахуй никому не впёрлась. не обессудьте.
некоторые товарищи продвигают идею, что комфоргная работа с OBS возможна при помощи "простого" браузера. лукавят сцуки, хотя... по мне так для работы необходим и браузер и "osc" - инструмент работы в командной строке. браузер как правило открывается на странице "Status Monitor" - мониторинг состояния всего проекта, чертовски удобно, а всё остальное делается при помощи командной строки. да и возможностей у "osc" на порядок больше.
вполне нормально, что при рисовании своего первого пакета/спек-файла и попытках разобраться с ошибками вы, вероятно, слегонца охуеете от количества найденных недочётов в двух строчках Вашего неповторимого спека. поэтому кратенько пробегусь по наиболее часто встречающимся макросам/(переменным), способным облегчить Ваш тяжкий труд (или свести Вас в могилу, ежели нет понимания, как оно работает и нахуя оно нам надо).
%{_tmppath} - макрос, который принято использовать при указании каталога, где будет происходить сборка. например BuildRoot: %{_tmppath}/%{name}-%{version}-build
%{name} - этот макрос содержит строку, что вы ввели как имя пакета
%{version} - соответственно версия пакета
%{_libdir} - в зависимости от архитектуры (x86; x86-64) и в соответствии с FHS (Filesystem Hierarchy Standard) указывает на директорию для установки библиотек (либок). в нашем случае это /usr/lib или /usr/lib64
%{_datadir} - директория для "данных" - /usr/share
%{_sysconfdir} - директория для конфигурационных файлов - /etc
%{_bindir} - бинарники - /usr/bin
%{_sbindir} - бинарники суперпользователя (рутовые) - /usr/sbin
%{_initrddir} - директория для скриптов, управляющих запуском/(остановкой, мониторингом и т.п.) сервисов/служб - /etc/init.d
%{_docdir} - для документации. обычно это - /usr/share/doc/packages/
%{_mandir} - наши "мэны" - /usr/share/man
%{buildroot} == $RPM_BUILD_ROOT == %{_tmppath}/%{name}-%{version}-build (это именно то, что вы внесли в BuildRoot: секцию спек-файла)
%{SOURCE} == $RPM_SOURCE_DIR/%{name}-%{version}.tar.* (Ваши исходники), соответственно если исходников (Source: ...) несколько, то %{SOURCE1} , %{SOURCE2} .... %{SOURCEn}
$RPM_SOURCE_DIR - в нашем случае это /usr/src/packages/SOURCES
%{py_ver} - версия установленного в системе пакета python. очень полезно использовать при сборке для разных платформ. например: %{_libdir}/python%{py_ver}/site-packages/* (пример из секции %files)
"прогрепать" все (ну или большинство) доступных вариантов можно в следующих файлах:
> rpm -ql rpm | grep macro
вот ещё статейка с более подробным описанием макросов - RPM_Macros.
перед тем, как вы будете рисовать строку "Group: blah-blah-blah", потрудитесь ознакомиться с RPM_Groups - регламентированными группами для rpm пакетов. если вам повезло и в пакете есть "*.desktop" файл, то учите макрос %suse_update_desktop_file и freedesktop-овы спеки на desktop файло для меню.
ежели кто подумал, что "это - пиздец, детка...", то чел круто ошибся, ибо о работе с модулями ядра мы поговорим в другой раз. сейчас чуток отсебятины.
допустим, что вы таки заколбасили пакетик в OBS, он собрался и краткий миг оргазма потряс ваши чресла. теперь предположим, что ваши исходники состоят всего из двух файлов (да, мы, бля, живём в идеальном мире!) - собсно затаренных сырцов и спек-файла. и тут возникла идея сделать апдейт. не знаю кто как, а я заебался в первый раз тыкать на кнопочки в броузере, ждать пока оно "прохавает", что пора что-то делать и т.п. поэтому поставил "osc" и потихоньку осваиваю эту команду по мере необходимости.
> osc help
> osc help НЕПОНЯТНАЯ_КОМАНДА
ну эт как-бы ясно. аз, буки, веди, глаголь и т.п.
> osc co PROJECT [PACKAGE] [FILE]
вытащит на локальный диск копию из OBS и далее развлекайтесь. для удобства лучше тащить сразу весь проект и делать бэкапы регулярно (на всякий). для себя набросал пару-тройку консольных команд для упрощения рутинных действий:
* апдейт OBS (то есть мы наколбасили что-то в локальной копии и хотим чтобы в OBS стало именно так, как и у нас на диске) для одного пакета. "становимся" (>cd) в PROJECT/PACKAGE и выполняем "> osc_up":
> cat `which osc_up `
#!/bin/sh
osc addremove && osc ci -m "updates, honey!"
#EOF
* смотрим логи (для openSUSE репозиториев!):
> cat `which osc_wl `
#!/bin/sh
if [ "$2" == "" ] ; then
arch="i586"
else
arch="x86_64"
fi
osc bl openSUSE_$1 $arch
#EOF
то есть "> osc_wl 11.1 1" покажет нам полный лог сборки пакета для openSUSE-11.1 (x86-64).
* глобальный апдейт проекта (из "локальной копии" -> в OBS, игнорируя мои служебные директории "snapshots" и "test"):
> cat update_from_local_to_OBS
#!/bin/sh
export components="`find ./ -maxdepth 1 -type d | sed 's/\.\///' | grep -v snapshots | grep -v test `"
for a1 in $components ; do
cd $a1
osc addremove && osc ci -m "sweet updates are roll-in!"
cd ../
done
#EOF
и последнее о чём хотел попиздеть - это о создании "One Click Install" файлов. что-то там на эту тему в приведённых ранее сцылках уже пробегало, так что коли не интересно - неволить не смею. пример, как это выглядит:
Тыц по сцылке!
и там красуются такие все из себя крутые файлы: E17_Base.ymp и E17_Metapackage.ymp. стоит только "клацнуть" по ним, как вылезет ненавязчивое предложение установить в систему хуеву тонну нужного и полезного софта. нра? то-то!
если кто-то думает, что надо локально создать именно "*.ymp" файлик по образу и подобию, а потом просто "закинуть" в репо - то этот кто-то безнадёжный романтик. время читать секцию Create_Patterns и пробовать свои силы.
единственное, что меня ломает учить - это OBS API. зарекаться не буду, хотя...
продолжение следует...
*/
вторник, 24 марта 2009 г.
понедельник, 23 марта 2009 г.
E17 systray appeared in svn! thanks to "k-s"!
/*
свершилось... товарищ k-s (известный в миру как Gustavo Sverzut Barbieri) прикрутил сегодня черновой вариант систрея для Enlightenment-DR17!
есть недоработки, но "лёд тронулся, Господа!". релиз DR17 ориентировочно запланирован на осень-зиму сего года. ура, Товарищи! ждём-с!
*/
свершилось... товарищ k-s (известный в миру как Gustavo Sverzut Barbieri) прикрутил сегодня черновой вариант систрея для Enlightenment-DR17!
есть недоработки, но "лёд тронулся, Господа!". релиз DR17 ориентировочно запланирован на осень-зиму сего года. ура, Товарищи! ждём-с!
*/
среда, 18 марта 2009 г.
OBS - openSUSE Build Service или "Одна Баба Сказала..."
/*
дамы и господа,
это - первая заметка о некоторых трюках при работе с замечательным сервисом openSUSE/Novell - openSUSE Build Service. если Вас интересуют какие-то детали или Вы желаете задать вопрос - оставляйте комментарии. постараюсь ответить.
недавно прислали очень поучительный экспромт о занятиях с детишками в детском саду. его и буду использовать в качестве "оглавления". поехали...
Занятие для организованных детских групп ДДОУ "Детский садик Светлячок".
Тема: "Автодорожное движение".
Учитель громким голосом четко произносит фразу, оканчивая ее вопросительной интонацией.
Дети хором произносят ответ.
УЧИТЕЛЬ: Кто король далеких трасс?
ДЕТИ: КАМАЗ!
абсолютно верно и пгавильно подмечено! формат rpm - наше фсио! остальное - от лукавого. а как же убунту и ".deb"? - очень неудобно разбираться откуда ноги растут у "dh_make". другими словами: spec файл - это святая Библия, где всё написано от и до. если встретился непонятный макрос - например %configure - набираем:
> rpmbuild --eval %configure
и смотрим что именно он означает. хотим написать свой макрос? - легко! читаем:
man rpm
vim /usr/share/doc/packages/rpm/manual/macros
и заглянем в "/usr/share/doc/packages/rpm/manual/" из чистого любопытства - там таки есть что почитать перед сном. по сравнению с rpm другие форматы пакетов выглядят как набор костылей. и не надо мне рассказывать, что EBUILD (Gentoo) рулит. любое использование USE флага автоматом означает невозможность стандартизировать результат и, как следствие, непригодность этого поделия в Production. а все типа "оптимизации", получаемые при "гибкой" сборке, можно спустить в унитаз чуток обновив железо. кроме того, rpm никоим разом не мешает делать спецсборки софта для тех же кластерных вычислений или же для работы с видео (как пример).
Что же такое этот OBS (openSUSE Build Service)? это система, которая позволяет создавать пакеты для всех основных дистрибутивов Linux, включая RH, Debian, Ubuntu и иже с ними. ежели по-простому, то внутрь ты пихаешь исходники и инструкцию по сборке, а на выходе получаешь готовые красивые КОШЕРНЫЕ пакеты. кошерные - ибо существуют некоторые наборы правил, которые мейнтейнер (далее буду пользовать термин "упаковщик") обязан соблюдать. под правилами также подразумевается наличие систем проверок готовых пакетов. то бишь устанавливая пакет из OBS лузер (в теории) имеет возможность полностью проконтролировать сборку и увериться, что ставит "кошерный продукт".
УЧИТЕЛЬ: Кто гремит и весь в пыли?
ДЕТИ: Жигули!
УЧИТЕЛЬ: Кто проедет грязь игриво?
ДЕТИ: Нива!
УЧИТЕЛЬ: Кушай кашу "Геркулес", купит папа?
ДЕТИ: Мерседес!
для пользования OBS необходимо наличие учётной записи в Novell и посещение стартовой страницы для получения базовых инструкций. скорее всего вводная в OBS более подойдёт для первого знакомства с системой. нет ни малейшего желания пересказывать "бояны", поэтому сделаю следующие допущения:
* вы прониклись мощью и красотой решения, получили учётку в Novell, создали свой домашний проект и, при помощи Web-gui (броузера) сваяли свой первый пакет.
* пакет этот нихуя не собирался как надо до тех пор, пока вы не прорюхали великий смысл в строках "BuildRequires: список DEVEL-пакетов (через пробел), необходимых для сборки Вашего первенца"
* всё собралось, но не везде. вы ещё раз пофтыкали инструкцию как компилять для разных дистрибутивов, обматерили всех "умников", дающих разное название одинаковым сущностям/пакетвм, взмолились о глобальной стандартизации, но таки сваяли новый spec файл.
* оно даже собралось, но проверки собранного пакета сказали Вам, что сборка прошла не по фэн-шую и предложилисходить нахуй набраться побольше опыта и исправить замеченные недостатки.
* у Вас оформилось светлая мечта уебать аффторов "проверок" чем-нить тяжёлым по умной голове, послать всю затею с OBS куда подальше и "включить идиота" на полную катушку - "Какие мейнтейнеры? "ПРЕВЕД" надо говорить разработчикам. Очнитесь. Задача мейтейнеров проста как 2x2- собрать из сырцов бинарики, собрать их в пакеты с учетом зависимостей, и положить их правильную ветку. Они вобще не должны "допиливать" что то до ума." - это высказывание одного из неофитов, отрицающих очевидное. "незнание законов не освобождает от ответственности"©
УЧИТЕЛЬ: За рулем бандитский тип, а машина эта?
ДЕТИ: Джип!
УЧИТЕЛЬ: Оштрафует, хоть ты тресни - это дядя?
ДЕТИ: ДэПээС-ник!
УЧИТЕЛЬ: Кто не дружит с головой? Это дядя...
ДЕТИ: Постовой!
дабы не уподобляться "дяде, что не дружит с головой" таки стоит осознать несколько прописных истин, как то:
* любые правила упорядочивают хаос;
* в данном контексте существующие проверки ставят целью обезопасить конечного Пользователя и указать "упаковщику" на некоторые очевидные оплошности в пакете;
* врага надо знать "в лицо"!
изучением этого "врага" и предлагаю заняться далее.
текущая система проверок уже готовых пакетов состоит из двух независимых друг от друга уровней (другими словами: в какой хронологической последовательности собранные пакеты проходят эти проверки - совершенно не важно). первый - это rpmlint проверки. детальное описание оных вы найдёте по ранее приведённой ссылке. мы можем полностью их контролировать. в секции "Supressing False Positives" описана методика подавления "фиктивных" ошибок. но, как всегда собственно, есть "нюансы"... о них и поговорим.
перво-наперво читаем:
> man rpmlint
после чего смотрим на детали (если нам жуть как интересен сам механизм проверок):
> rpm -ql rpmlint
потом начинаем разбираться в том, "виноват" ли rpmlint в ошибке со сборкой нашего пакета. понять это очень просто. если проверка говорит, что "(Badness: 10000)" (допустим) - то это "наш" rpmlint. также он очень вежливо пишет какая именно из множества предусмотренных проверок "отоварила" нас выигрышем в джекпот:
permissions-file-setuid-bit (Badness: 10000) /usr/bin/БИНАРЬ is packaged with setuid/setgid bits (04555)
вежливо благодарим за предоставленную информацию и чешем репу. в данном конкретном примере нам сделали серьёзную предъяву, что собираемый нами пакет есть злобное некошерное чудовище, которому не место на системах добропорядочных граждан. однако, иногда (в ОЧЕНЬ редких случаях) наличие SUID-bit оправдано. предположим, что это именно такой случай. задача - поблагодарить OBS за предоставленную информацию и вежливо попросить заткнуться на будущее (не навешивать пакету штрафных очков).
* создаём в "исходниках" файл с расширением ".rpmlintrc". допустим Ваш спек называется "ПЕРВЕНЕЦ.spec", тогда созданный только что файл должен называться "ПЕРВЕНЕЦ.rpmlintrc"
* добавляем инструкцию насчёт нашего "проблемного" (по мнению OBS) бинаря:
addFilter("permissions-file-setuid-bit.*.*")
мы только что поставили монолитную могильную плиту над всеми попытками rpmlint-а заорать, что наш пакет имеет плохой SUID-bit на бинарнике. это конечно же неправильно. конечно же надо разобраться в вопросе и попытаться как-то обойтись без подобных крайностей. поэтому всем рекомендую перечитать одну из моих прежних заметок, где история именно с этой проверкой "моего" пакета расписана от "А" до "Я". кроме того, там есть пример "умной" brp проверки, о которой наша речь пойдёт далее. фраза "as responsive as a wall" почему-то постоянно приходит мне в голову применимо к данному случаю... интересно, что бы сказал по этому поводу дедушка Фрейд?
обращаю внимание публики, что файл "ПЕРВЕНЕЦ.rpmlintrc" не обязательно вносить в "ПЕРВЕНЕЦ.spec" как "Source?:". это конечно же диктуется правилами хорошего тона, но... увы и ах.
мы все, к сожалению, живём в реальном мире, а любые проверки подразумевают некий "идеальный мир" (сугубо с позиций АВТОРА проверок), к которому надо стремиться. это и есть суть возможных конфликтов. "What we've got here is a failure to communicate..." /Guns'n'Roses/
УЧИТЕЛЬ: Десять трупов, все в кисель, в ДТП у нас?
ДЕТИ: Газель!
УЧИТЕЛЬ: Кто на встречной всякий раз?
ДЕТИ: Пида@ас!
УЧИТЕЛЬ: Мигалки, @ляди и понты, за пивом ехали?
ДЕТИ: Менты!
второй эшелон "обороны" - это появившиеся в версии openSUSE-11.1 так называемые "brp" проверки. информации о них - море (попробуйте найти хоть одно внятное описание в openSUSE Wiki). как пример можно сразу смело давить на эту ссылку поиска и чесать репу до полного просветления. удачи.
официальная точка зрения по этому вопросу такова (несколько упрощённый вариант ессно): "brp проверки - наше фсио! отключить их нельзя! все пакеты должны проходить проверку brp!" лучше всего об этом скажут воспитанники детской группы ДДОУ "Детский садик Светлячок":
УЧИТЕЛЬ: Красный свет горит не зря, нету хода?
ДЕТИ: ни @уя!
на данный момент все пакеты для openSUSE-11.1/Factory проходят "brp" проверки в обязательном порядке. к чему приводит подобный подход - уже описывал. "благими намерениями вымощена дорога в ад"© - что есть, то есть. в основе-то своей идея стоящая. разработать правила, которым должны следовать все. только реализация хромает. наличие неких "белых списков" для якобы "кошерных" пакетов, куда всем прочим никогда не попасть, ставит на этой идее могильный крестик. махонький такой, ибо есть "нюансы", о которых и поговорим ниже.
суть "brp" проверок очень бледно отражена в трёх пакетах:
brp-check-suse | build root policy check scripts | package
brp-check-suse | relaxed build checks | patch
librpcsecgss | Library Implementing GSSAPI Security for ONC RPC | package
сами же "проверки" уже "зашиты" в пакет "rpm" ("зашиты" - это неправда!). можно на них полюбоваться кстати:
> rpm -ql rpm | grep brp | grep -w "rpm"
или
> find `rpm -ql rpm | grep brp | grep -w "rpm" ` \
-print -exec cat {} \;
делов-то. а на самом деле посмотреть на механизм проверок можно (imho) только в случае установки и запуска локально сервера OBS. "brp" проверки именно "зашивают" в конфигурацию проекта/платформы. например: в openSUSE-10.3/11.0 их нет, а в openSUSE-11.1/Factory они есть.
другими словами, разрешено всё, что не запрещено. спектр проверок довольно широк. от "правильно" (по мнению авторов ессно) сформированного "*.desktop" файла и до уже упомянутых ранее "некошерных" сервисов D-BUS (без которых повторюсь не будут работать пакеты типа "Wicd", "Exalt" и прочие). с одной стороны это здорово - нахуя в openSUSE лишние пакеты? да и если Вы хотите собирать для openSUSE Community - то есть же Packman! (в Packman Community communication skills более развиты кстати...) с другой же стороны это вполне может привести к тому, что в OBS в первую очередь будут собирать пакеты для RH/Ubuntu/MDK, а потом чесать репу насчёт сборки для текущей версии openSUSE. именно эту картину все и наблюдали в момент релиза версии openSUSE-11.1. доступного софта по сравнению с версией 11.0 было значительно меньше, ибо "упаковщики" в течение следующего полугода старались "вытянуть" свои проекты на уровень 11.0.
на сегодня о сути проверок можно догадываться по именам файлов, их содержащим. в скобках - моё imho:
00-check-install-rpms (этот пакет вообще может быть установлен... производится реальная установка пакета в chroot-е)
01-check-debuginfo (проверка на "пустоту" в пакете -debug)
02-check-gcc-output (насколько серьёзны были предупреждения компилятора во время сборки. для проверки используется реальный лог сборки пакета)
03-check-binary-kernel-log (что-то связанное с корректной установкой бинарей, хотя хз, запамятовал)
04-check-filelist (собсно проверка содержимого пакета на соответствие его "таможенной декларации")
05-check-invalid-requires (ибо нехер рисовать кривые зависимости ручками, да!)
06-check-installtest (если вы думаете, что вы тут самый умный и наколбасили левые %pre*/%pos* скрипты/макросы - то самое времясходить нахуй)
08-check-permissions (весьма здравая идея, но сам тест - мог быть и получше...)
09-check-packaged-twice (безобидный тест на "декларирование" в %files файла дважды/трижды/etc)
10-check-lanana (хз)
11-check-pkgconfig-deps (если Ваши "*.pc" файлы - файлы для "pkg-config" - содержат некорректную информацию - пришло время ревизии!)
12-check-libtool-deps (очень тупой и бесполезный тест, ибо правила хорошего тона рекомендуют к буям вырезать из пакета все {*.a;*.la} файлы - мамо, оно нам не надо...)
13-check-invalid-provides (на тему излишнего усердия при ручном заполнении строк "Provides:" - эти поля очень неплохо заполняются автоматически и не надо тут особо вы@бываться)
14-check-gconf-scriptlets (хз, не попадались)
99-check-remove-rpms (проверка на успешное удаление пакета с реальной деинсталляцией из chroot)
всё, что приведено выше, на первый взгляд пропитано самой Добротой и Заботой о ближнем (и о дальнем, что характерно), но в реальной жизни появляются... да-да-да! "нюансы"...
одно из отличий "brp" от "rpmlint"-а в том, что "плохие отметки" (Badness: X) "brp" тебе не ставит. ежели чего не так - ты сразу жеидёшь нахуй в пролёте вместе со своим собранным пакетом под звуки фанфар, бурные апплодисменты и без лишних объяснений.
разберём типовую ситуацию. есть дивный блок проверки "*.desktop" файлов, который иногда неимоверно бесит. одна из "выдающихся" проверок может не найдя иконки (упомянутой в пресловутом *.desktop файле!) допустим в %{_datadir}/pixmaps/ сказать:
ERROR: Icon file not installed:
и отправить тебя вместе с пакетом в путешествие пешком. как минимум есть два случая, при которых эта "проверка" абсолютно бесполезна:
1) если иконка установлена в %{_datadir}/icons/ (да, не по фэн-шую, но работает!)
2) если мы не хотим рисовать свою иконку и тянуть в зависимостях к нашему пакету какую-то из доступных тем иконок (что imho абсолютно оправдано и разумно. ну не будет в xdg менюшке у нашего горе-приложения иконки, и что?).
пишем письмо по адресу, упомянутому в OBS, предназначенному для решения подобных "неувязок" - stbinner@suse.de . идём нахуй, ибо ещё в октябре-декабре прошлого года этот Товарищ поменял e-mail, а о новом ящике простые смертные не знают ничегошеньки. естественно, что после этого мы получаем нехилую мотивациюпослать "brp" ф пизду исправить в пакете все недочёты, обнаруженные милыми "brp" проверками. такая возможность конечно же есть (пока что).
универсальный рецепт прост: внимательно изучаем логи сборки с найденными ошибками и исправляем их, собирая Ваш пакет в гармонии с окружающей средой. если же Вы внимательно прочитали заметку (сходив по всем приведённым ссылкам), то "секретный код" как отключить все "brp" проверки Вами уже найден.
удачи.
P.S. планируется в недалёком будущем рассмотреть некоторые аспекты работы с OBS при помощи Web-gui и командной строки, описать процесс создания "One-Click-Install" файлов, рассмотреть создание модулей ядра и просто попиздеть о том о сём... пишите камменты, они рулят!
*/
дамы и господа,
это - первая заметка о некоторых трюках при работе с замечательным сервисом openSUSE/Novell - openSUSE Build Service. если Вас интересуют какие-то детали или Вы желаете задать вопрос - оставляйте комментарии. постараюсь ответить.
недавно прислали очень поучительный экспромт о занятиях с детишками в детском саду. его и буду использовать в качестве "оглавления". поехали...
Занятие для организованных детских групп ДДОУ "Детский садик Светлячок".
Тема: "Автодорожное движение".
Учитель громким голосом четко произносит фразу, оканчивая ее вопросительной интонацией.
Дети хором произносят ответ.
УЧИТЕЛЬ: Кто король далеких трасс?
ДЕТИ: КАМАЗ!
абсолютно верно и пгавильно подмечено! формат rpm - наше фсио! остальное - от лукавого. а как же убунту и ".deb"? - очень неудобно разбираться откуда ноги растут у "dh_make". другими словами: spec файл - это святая Библия, где всё написано от и до. если встретился непонятный макрос - например %configure - набираем:
> rpmbuild --eval %configure
и смотрим что именно он означает. хотим написать свой макрос? - легко! читаем:
man rpm
vim /usr/share/doc/packages/rpm/manual/macros
и заглянем в "/usr/share/doc/packages/rpm/manual/" из чистого любопытства - там таки есть что почитать перед сном. по сравнению с rpm другие форматы пакетов выглядят как набор костылей. и не надо мне рассказывать, что EBUILD (Gentoo) рулит. любое использование USE флага автоматом означает невозможность стандартизировать результат и, как следствие, непригодность этого поделия в Production. а все типа "оптимизации", получаемые при "гибкой" сборке, можно спустить в унитаз чуток обновив железо. кроме того, rpm никоим разом не мешает делать спецсборки софта для тех же кластерных вычислений или же для работы с видео (как пример).
Что же такое этот OBS (openSUSE Build Service)? это система, которая позволяет создавать пакеты для всех основных дистрибутивов Linux, включая RH, Debian, Ubuntu и иже с ними. ежели по-простому, то внутрь ты пихаешь исходники и инструкцию по сборке, а на выходе получаешь готовые красивые КОШЕРНЫЕ пакеты. кошерные - ибо существуют некоторые наборы правил, которые мейнтейнер (далее буду пользовать термин "упаковщик") обязан соблюдать. под правилами также подразумевается наличие систем проверок готовых пакетов. то бишь устанавливая пакет из OBS лузер (в теории) имеет возможность полностью проконтролировать сборку и увериться, что ставит "кошерный продукт".
УЧИТЕЛЬ: Кто гремит и весь в пыли?
ДЕТИ: Жигули!
УЧИТЕЛЬ: Кто проедет грязь игриво?
ДЕТИ: Нива!
УЧИТЕЛЬ: Кушай кашу "Геркулес", купит папа?
ДЕТИ: Мерседес!
для пользования OBS необходимо наличие учётной записи в Novell и посещение стартовой страницы для получения базовых инструкций. скорее всего вводная в OBS более подойдёт для первого знакомства с системой. нет ни малейшего желания пересказывать "бояны", поэтому сделаю следующие допущения:
* вы прониклись мощью и красотой решения, получили учётку в Novell, создали свой домашний проект и, при помощи Web-gui (броузера) сваяли свой первый пакет.
* пакет этот нихуя не собирался как надо до тех пор, пока вы не прорюхали великий смысл в строках "BuildRequires: список DEVEL-пакетов (через пробел), необходимых для сборки Вашего первенца"
* всё собралось, но не везде. вы ещё раз пофтыкали инструкцию как компилять для разных дистрибутивов, обматерили всех "умников", дающих разное название одинаковым сущностям/пакетвм, взмолились о глобальной стандартизации, но таки сваяли новый spec файл.
* оно даже собралось, но проверки собранного пакета сказали Вам, что сборка прошла не по фэн-шую и предложили
* у Вас оформилось светлая мечта уебать аффторов "проверок" чем-нить тяжёлым по умной голове, послать всю затею с OBS куда подальше и "включить идиота" на полную катушку - "Какие мейнтейнеры? "ПРЕВЕД" надо говорить разработчикам. Очнитесь. Задача мейтейнеров проста как 2x2- собрать из сырцов бинарики, собрать их в пакеты с учетом зависимостей, и положить их правильную ветку. Они вобще не должны "допиливать" что то до ума." - это высказывание одного из неофитов, отрицающих очевидное. "незнание законов не освобождает от ответственности"©
УЧИТЕЛЬ: За рулем бандитский тип, а машина эта?
ДЕТИ: Джип!
УЧИТЕЛЬ: Оштрафует, хоть ты тресни - это дядя?
ДЕТИ: ДэПээС-ник!
УЧИТЕЛЬ: Кто не дружит с головой? Это дядя...
ДЕТИ: Постовой!
дабы не уподобляться "дяде, что не дружит с головой" таки стоит осознать несколько прописных истин, как то:
* любые правила упорядочивают хаос;
* в данном контексте существующие проверки ставят целью обезопасить конечного Пользователя и указать "упаковщику" на некоторые очевидные оплошности в пакете;
* врага надо знать "в лицо"!
изучением этого "врага" и предлагаю заняться далее.
текущая система проверок уже готовых пакетов состоит из двух независимых друг от друга уровней (другими словами: в какой хронологической последовательности собранные пакеты проходят эти проверки - совершенно не важно). первый - это rpmlint проверки. детальное описание оных вы найдёте по ранее приведённой ссылке. мы можем полностью их контролировать. в секции "Supressing False Positives" описана методика подавления "фиктивных" ошибок. но, как всегда собственно, есть "нюансы"... о них и поговорим.
перво-наперво читаем:
> man rpmlint
после чего смотрим на детали (если нам жуть как интересен сам механизм проверок):
> rpm -ql rpmlint
потом начинаем разбираться в том, "виноват" ли rpmlint в ошибке со сборкой нашего пакета. понять это очень просто. если проверка говорит, что "(Badness: 10000)" (допустим) - то это "наш" rpmlint. также он очень вежливо пишет какая именно из множества предусмотренных проверок "отоварила" нас выигрышем в джекпот:
permissions-file-setuid-bit (Badness: 10000) /usr/bin/БИНАРЬ is packaged with setuid/setgid bits (04555)
вежливо благодарим за предоставленную информацию и чешем репу. в данном конкретном примере нам сделали серьёзную предъяву, что собираемый нами пакет есть злобное некошерное чудовище, которому не место на системах добропорядочных граждан. однако, иногда (в ОЧЕНЬ редких случаях) наличие SUID-bit оправдано. предположим, что это именно такой случай. задача - поблагодарить OBS за предоставленную информацию и вежливо попросить заткнуться на будущее (не навешивать пакету штрафных очков).
* создаём в "исходниках" файл с расширением ".rpmlintrc". допустим Ваш спек называется "ПЕРВЕНЕЦ.spec", тогда созданный только что файл должен называться "ПЕРВЕНЕЦ.rpmlintrc"
* добавляем инструкцию насчёт нашего "проблемного" (по мнению OBS) бинаря:
addFilter("permissions-file-setuid-bit.*.*")
мы только что поставили монолитную могильную плиту над всеми попытками rpmlint-а заорать, что наш пакет имеет плохой SUID-bit на бинарнике. это конечно же неправильно. конечно же надо разобраться в вопросе и попытаться как-то обойтись без подобных крайностей. поэтому всем рекомендую перечитать одну из моих прежних заметок, где история именно с этой проверкой "моего" пакета расписана от "А" до "Я". кроме того, там есть пример "умной" brp проверки, о которой наша речь пойдёт далее. фраза "as responsive as a wall" почему-то постоянно приходит мне в голову применимо к данному случаю... интересно, что бы сказал по этому поводу дедушка Фрейд?
обращаю внимание публики, что файл "ПЕРВЕНЕЦ.rpmlintrc" не обязательно вносить в "ПЕРВЕНЕЦ.spec" как "Source?:". это конечно же диктуется правилами хорошего тона, но... увы и ах.
мы все, к сожалению, живём в реальном мире, а любые проверки подразумевают некий "идеальный мир" (сугубо с позиций АВТОРА проверок), к которому надо стремиться. это и есть суть возможных конфликтов. "What we've got here is a failure to communicate..." /Guns'n'Roses/
УЧИТЕЛЬ: Десять трупов, все в кисель, в ДТП у нас?
ДЕТИ: Газель!
УЧИТЕЛЬ: Кто на встречной всякий раз?
ДЕТИ: Пида@ас!
УЧИТЕЛЬ: Мигалки, @ляди и понты, за пивом ехали?
ДЕТИ: Менты!
второй эшелон "обороны" - это появившиеся в версии openSUSE-11.1 так называемые "brp" проверки. информации о них - море (попробуйте найти хоть одно внятное описание в openSUSE Wiki). как пример можно сразу смело давить на эту ссылку поиска и чесать репу до полного просветления. удачи.
официальная точка зрения по этому вопросу такова (несколько упрощённый вариант ессно): "brp проверки - наше фсио! отключить их нельзя! все пакеты должны проходить проверку brp!" лучше всего об этом скажут воспитанники детской группы ДДОУ "Детский садик Светлячок":
УЧИТЕЛЬ: Красный свет горит не зря, нету хода?
ДЕТИ: ни @уя!
на данный момент все пакеты для openSUSE-11.1/Factory проходят "brp" проверки в обязательном порядке. к чему приводит подобный подход - уже описывал. "благими намерениями вымощена дорога в ад"© - что есть, то есть. в основе-то своей идея стоящая. разработать правила, которым должны следовать все. только реализация хромает. наличие неких "белых списков" для якобы "кошерных" пакетов, куда всем прочим никогда не попасть, ставит на этой идее могильный крестик. махонький такой, ибо есть "нюансы", о которых и поговорим ниже.
суть "brp" проверок очень бледно отражена в трёх пакетах:
brp-check-suse | build root policy check scripts | package
brp-check-suse | relaxed build checks | patch
librpcsecgss | Library Implementing GSSAPI Security for ONC RPC | package
сами же "проверки" уже "зашиты" в пакет "rpm" ("зашиты" - это неправда!). можно на них полюбоваться кстати:
> rpm -ql rpm | grep brp | grep -w "rpm"
или
> find `rpm -ql rpm | grep brp | grep -w "rpm" ` \
-print -exec cat {} \;
делов-то. а на самом деле посмотреть на механизм проверок можно (imho) только в случае установки и запуска локально сервера OBS. "brp" проверки именно "зашивают" в конфигурацию проекта/платформы. например: в openSUSE-10.3/11.0 их нет, а в openSUSE-11.1/Factory они есть.
другими словами, разрешено всё, что не запрещено. спектр проверок довольно широк. от "правильно" (по мнению авторов ессно) сформированного "*.desktop" файла и до уже упомянутых ранее "некошерных" сервисов D-BUS (без которых повторюсь не будут работать пакеты типа "Wicd", "Exalt" и прочие). с одной стороны это здорово - нахуя в openSUSE лишние пакеты? да и если Вы хотите собирать для openSUSE Community - то есть же Packman! (в Packman Community communication skills более развиты кстати...) с другой же стороны это вполне может привести к тому, что в OBS в первую очередь будут собирать пакеты для RH/Ubuntu/MDK, а потом чесать репу насчёт сборки для текущей версии openSUSE. именно эту картину все и наблюдали в момент релиза версии openSUSE-11.1. доступного софта по сравнению с версией 11.0 было значительно меньше, ибо "упаковщики" в течение следующего полугода старались "вытянуть" свои проекты на уровень 11.0.
на сегодня о сути проверок можно догадываться по именам файлов, их содержащим. в скобках - моё imho:
00-check-install-rpms (этот пакет вообще может быть установлен... производится реальная установка пакета в chroot-е)
01-check-debuginfo (проверка на "пустоту" в пакете -debug)
02-check-gcc-output (насколько серьёзны были предупреждения компилятора во время сборки. для проверки используется реальный лог сборки пакета)
03-check-binary-kernel-log (что-то связанное с корректной установкой бинарей, хотя хз, запамятовал)
04-check-filelist (собсно проверка содержимого пакета на соответствие его "таможенной декларации")
05-check-invalid-requires (ибо нехер рисовать кривые зависимости ручками, да!)
06-check-installtest (если вы думаете, что вы тут самый умный и наколбасили левые %pre*/%pos* скрипты/макросы - то самое время
08-check-permissions (весьма здравая идея, но сам тест - мог быть и получше...)
09-check-packaged-twice (безобидный тест на "декларирование" в %files файла дважды/трижды/etc)
10-check-lanana (хз)
11-check-pkgconfig-deps (если Ваши "*.pc" файлы - файлы для "pkg-config" - содержат некорректную информацию - пришло время ревизии!)
12-check-libtool-deps (очень тупой и бесполезный тест, ибо правила хорошего тона рекомендуют к буям вырезать из пакета все {*.a;*.la} файлы - мамо, оно нам не надо...)
13-check-invalid-provides (на тему излишнего усердия при ручном заполнении строк "Provides:" - эти поля очень неплохо заполняются автоматически и не надо тут особо вы@бываться)
14-check-gconf-scriptlets (хз, не попадались)
99-check-remove-rpms (проверка на успешное удаление пакета с реальной деинсталляцией из chroot)
всё, что приведено выше, на первый взгляд пропитано самой Добротой и Заботой о ближнем (и о дальнем, что характерно), но в реальной жизни появляются... да-да-да! "нюансы"...
одно из отличий "brp" от "rpmlint"-а в том, что "плохие отметки" (Badness: X) "brp" тебе не ставит. ежели чего не так - ты сразу же
разберём типовую ситуацию. есть дивный блок проверки "*.desktop" файлов, который иногда неимоверно бесит. одна из "выдающихся" проверок может не найдя иконки (упомянутой в пресловутом *.desktop файле!) допустим в %{_datadir}/pixmaps/ сказать:
ERROR: Icon file not installed:
и отправить тебя вместе с пакетом в путешествие пешком. как минимум есть два случая, при которых эта "проверка" абсолютно бесполезна:
1) если иконка установлена в %{_datadir}/icons/ (да, не по фэн-шую, но работает!)
2) если мы не хотим рисовать свою иконку и тянуть в зависимостях к нашему пакету какую-то из доступных тем иконок (что imho абсолютно оправдано и разумно. ну не будет в xdg менюшке у нашего горе-приложения иконки, и что?).
пишем письмо по адресу, упомянутому в OBS, предназначенному для решения подобных "неувязок" - stbinner@suse.de . идём нахуй, ибо ещё в октябре-декабре прошлого года этот Товарищ поменял e-mail, а о новом ящике простые смертные не знают ничегошеньки. естественно, что после этого мы получаем нехилую мотивацию
универсальный рецепт прост: внимательно изучаем логи сборки с найденными ошибками и исправляем их, собирая Ваш пакет в гармонии с окружающей средой. если же Вы внимательно прочитали заметку (сходив по всем приведённым ссылкам), то "секретный код" как отключить все "brp" проверки Вами уже найден.
удачи.
P.S. планируется в недалёком будущем рассмотреть некоторые аспекты работы с OBS при помощи Web-gui и командной строки, описать процесс создания "One-Click-Install" файлов, рассмотреть создание модулей ядра и просто попиздеть о том о сём... пишите камменты, они рулят!
*/
Сила Маркетинга (или чуток о том, как выдавать желаемое за действительное...)
/*
Что толку быть собой не ведая стыда,
Когда 15 баб резвятся у пруда...
/БГ/
чистота - залог здоровья, порядок - прежде всего, а стабильно работающая система - эт собсно наше всё. какого-то лешего в очередной раз решил проапгрейдить систему с openSUSE-11.0 до openSUSE-11.1 без форматирования рутового раздела. другими словами - апгрейд "на живую", при помощи "волшебной" команды:
sudo zypper dup
собственно решил проверить насколько рекомендации ведущих собаководов соответствуют истине. одну такую попытку Ваш покорный слуга уже описывал ранее. всё конечно же было сукесфули комплитэд (successfully completed), но, дай Бог памяти, текущую систему (11.0) таки ставил с чистого листа, с форматированием рутового раздела. итак нюансы:
1) даже если Вы в добром уме и трезвом здравии буква в буковку следовали "рекомендациям" - в результате (после первой перезагрузки) получится вариант, далёкий от идеала. почему? потому, что логика команды "zypper dup" -говно заточена на минимизацию трафика при апгрейде системы, а не на получение 100% стабильного результата (по крайней мере для openSUSE-11.0). но! всё это легко контролируется и не менее легко и очаровательно приводится в норму. об этом правда многие почему-то умалчивают, либо не обоняя "родное амбрэ", либо не владея техникой постановки любого вопроса раком для последующего сукесфули решения.
2) imho - если Вы можете позволить себе скачать/купить дистрибутив и поставить систему "с нуля" - то именно так и надобно поступать. к тому же форматирование партиции есть суть операция весьма и весьма пользительная...
3) ещё раз перечитайте пункт первый и будьте морально готовы к разгребанию Авгиевых конюшен...
а в чём же тогда смысл апгрейда системы подобным образом? элементарно, Уотсон! если вы - ньюб или неопытный лузер, которому худо-бедно каким-то макаром но удалось настроить систему (или же вы думаете, что она работает так, как Вам надо...), то подобная процедура (Вы не поверите!) сохранит ВСЕ Ваши конфиги! да-да-да! от grub-а и до vsftpd (до настроек в Вашем "хомяке" - $HOME каталоге) - всё останется как было, без глобальных изменений. поэтому суть есть собсно выбор: или Вы способны за 5-15 минут откатить конфиги из бэкапа и подрихтовать их для новой системы, или Вы намерены чуток поебаться с "мягким" апгрейдом. Вам выбирать...
собсно создать бэкап настроек можно при помощи шаблона ниже:
#!/bin/sh
mkdir -p ~/tmp/backup
cd ~/tmp/backup/
sudo tar -cvvjf "`date +%m%d%Y`_etc.tar.bz2" /etc
sudo tar -cvvjf "`date +%m%d%Y`_var_lib_rpm.tar.bz2" /var/lib/rpm
find ~ -maxdepth 1 -type f > ./"$USER"_home_rc && \
tar -cvvjf "`date +%m%d%Y`_home_rc.tar.bz2" -T ./"$USER"_home_rc
итак, вернёмся к нашим "баранам". Вы таки решились не травмировать свою нежную душу восстановлением конфигов, перебили адреса всех репозиториев на новую версию, зашли в консольку, дрожжащими ручонками накорябали (махнув 150 для смелости):
sudo zypper dup
и отправились баиньки, дабы за ночь системка выкачала пару-тройку гигабайт обновлений. урок нумеро уно: не надо обновлять "помойку". сперва откройте тот же YaST (если у Вас толстый канал и хороший провайдер) или воспользуйтесь "rpm -e $packages" и постарайтесь убрать лишнее. так будет проще. поскольку поднятый мной вопрос о компиляции драйверов вызвал оживлённую дискуссию и все мейнтейнеры модулей ядра сразу же добавили "Update" репозитории в свои проекты, то если Вы решились обновиться до текущего стабильного состояния 11.1 - останетесь без пакетов драйверов для ATI/NVIDIA (как минимум, ибо ядро уже обновилось, может ещё что-то "сломается"...). оно конечно же можно и ручками дрова прикрутить, потом, вспомнив, что надо доставить пакеты "kernel-source", "kernel-syms", "linux-kernel-headers", "gcc", "make" и напечатав "init 3" в строке логина. а первым делом забэкапьте и обнулите "/etc/zypp/locks" файл! какого буя об этом молчат "известные собаководы" - непонятно...
sudo cp /etc/zypp/locks /etc/zypp/locks.old
su
(введите Ваш рутовый пароль)
echo "" > /etc/zypp/locks
exit
после чего ещё раз проверьте новые репо и давите на педальку:
sudo zypper ref && sudo zypper dup
как только безобразие закончится - не спешите в ребут. если вам нужно поставить драйвер ATI/NVIDIA - убедитесь, что как минимум стоят упомянутые выше пакеты. также можно до перезагрузки открыть YaST -> Software Management и установить все апдейты, которые он предложит. перегружаемся. если надо ставить дрова - уходим в "init 3" и ставим. возвращаемся в "init 5" и оцениваем "масштаб катастрофы". на первый взбляд всё будет тип-топ. новое ядро, типа новые пакеты, новая система... сверху - шоколадка, а внутри - кокос. сразу было сладко, а теперь приступим к изучению того, что нам оставила команда "zypper dup".
* мантра первая: если вы были уверены в том, что имеете полное право собирать программы из исходников и устанавливать их при помощи "sudo make install" - с результатами разбирайтесь сами. это подтолкнёт вас к изучению формата rpm и написанию кошерных spec файлов в будущем...
* мантра вторая: "не ссы, прорвёмся". всё на самом деле не так уж и плохо, скорее даже наоборот.
* мантра третья: думай своей головой. если с чем-то не согласен и это у тебя работает - есть смысл так и оставить.
* мантра четвёртая:
"Жаль, подмога не пришла
Подкрепленья не прислали
Нас осталось только два
Нас с тобою наебали..."
/БГ/
чтобы в этом убедиться далеко ходить не надо. выполняем команды:
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
результат нам покажет сколько пакетов осталось в системе от старой версии. но это не всё.
export OLD_VERSION="(none)"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
это покажет сколько пакетов имеют сомнительное происхождение. может вы собирали их сами, может ставили хз откуда - всё надо перепроверить. осмелюсь предложить вариант.
cd /tmp
rpm -qai > ./packages1
less ./packages1
находим по шаблону "11.0" старый пакет, смотрим как оно называется и рисуем (с правами рута!):
export pac="zsnes llvm llvm-devel" && rpm -e --nodeps $pac ; zypper in $pac
вот таким вот нехитрым макаром надо пройтись по всем пакетам и добиться, чтобы
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
в результате в системе не осталось следов от старой версии. с export OLD_VERSION="(none)" проще. в данном случае большинство пакетов есть не что иное как ключи шифрования. оставить их или убрать зависит от Вас и вашего поведения. обращайте внимание на все сообщения при
export pac="PACKAGES" && rpm -e --nodeps $pac ; zypper in $pac
это очень важно! например:
export pac="libx264-60" && rpm -e --nodeps $pac ; zypper in $pac
команда просто удалит x264 бинарь из вашей новой системы и напишет, что для версии 11.1 такого пакета (libx264-60) нет. и правильно, ибо есть пакет/ы libx264-67 и libx264-65! то есть вам надо после сообщения, что "пакет типа не найден нихуя" нарисовать в консоли
sudo zypper se libx264
и посмотреть на "варианты". дело это довольно муторное, должен признать. кроме того есть "нюансы" другого плана...
предположим, что Вы питаете нежную любовь к дивному "продукту" - Pulseaudio и, также как и я, не видите в нём никакого смысла. если в версии openSUSE-11.0 можно было извернуться и не ставить/(не запускать) это быдлоподелие, то в 11.1 без подобного "костыля" не запустится например "Stardict" и ряд других программ. кушать, так сказать, подано, Господа...
ну а в целом оно конечно же очень пиздато. перебил репы, нарисовал "zypper ref && zypper dup" и получил полный апгрейд! без проблем! во как!
*/
Что толку быть собой не ведая стыда,
Когда 15 баб резвятся у пруда...
/БГ/
чистота - залог здоровья, порядок - прежде всего, а стабильно работающая система - эт собсно наше всё. какого-то лешего в очередной раз решил проапгрейдить систему с openSUSE-11.0 до openSUSE-11.1 без форматирования рутового раздела. другими словами - апгрейд "на живую", при помощи "волшебной" команды:
sudo zypper dup
собственно решил проверить насколько рекомендации ведущих собаководов соответствуют истине. одну такую попытку Ваш покорный слуга уже описывал ранее. всё конечно же было сукесфули комплитэд (successfully completed), но, дай Бог памяти, текущую систему (11.0) таки ставил с чистого листа, с форматированием рутового раздела. итак нюансы:
1) даже если Вы в добром уме и трезвом здравии буква в буковку следовали "рекомендациям" - в результате (после первой перезагрузки) получится вариант, далёкий от идеала. почему? потому, что логика команды "zypper dup" -
2) imho - если Вы можете позволить себе скачать/купить дистрибутив и поставить систему "с нуля" - то именно так и надобно поступать. к тому же форматирование партиции есть суть операция весьма и весьма пользительная...
3) ещё раз перечитайте пункт первый и будьте морально готовы к разгребанию Авгиевых конюшен...
а в чём же тогда смысл апгрейда системы подобным образом? элементарно, Уотсон! если вы - ньюб или неопытный лузер, которому худо-бедно каким-то макаром но удалось настроить систему (или же вы думаете, что она работает так, как Вам надо...), то подобная процедура (Вы не поверите!) сохранит ВСЕ Ваши конфиги! да-да-да! от grub-а и до vsftpd (до настроек в Вашем "хомяке" - $HOME каталоге) - всё останется как было, без глобальных изменений. поэтому суть есть собсно выбор: или Вы способны за 5-15 минут откатить конфиги из бэкапа и подрихтовать их для новой системы, или Вы намерены чуток поебаться с "мягким" апгрейдом. Вам выбирать...
/* лирическое отступление */
собсно создать бэкап настроек можно при помощи шаблона ниже:
#!/bin/sh
mkdir -p ~/tmp/backup
cd ~/tmp/backup/
sudo tar -cvvjf "`date +%m%d%Y`_etc.tar.bz2" /etc
sudo tar -cvvjf "`date +%m%d%Y`_var_lib_rpm.tar.bz2" /var/lib/rpm
find ~ -maxdepth 1 -type f > ./"$USER"_home_rc && \
tar -cvvjf "`date +%m%d%Y`_home_rc.tar.bz2" -T ./"$USER"_home_rc
/* звиздец лирического отступления */
итак, вернёмся к нашим "баранам". Вы таки решились не травмировать свою нежную душу восстановлением конфигов, перебили адреса всех репозиториев на новую версию, зашли в консольку, дрожжащими ручонками накорябали (махнув 150 для смелости):
sudo zypper dup
и отправились баиньки, дабы за ночь системка выкачала пару-тройку гигабайт обновлений. урок нумеро уно: не надо обновлять "помойку". сперва откройте тот же YaST (если у Вас толстый канал и хороший провайдер) или воспользуйтесь "rpm -e $packages" и постарайтесь убрать лишнее. так будет проще. поскольку поднятый мной вопрос о компиляции драйверов вызвал оживлённую дискуссию и все мейнтейнеры модулей ядра сразу же добавили "Update" репозитории в свои проекты, то если Вы решились обновиться до текущего стабильного состояния 11.1 - останетесь без пакетов драйверов для ATI/NVIDIA (как минимум, ибо ядро уже обновилось, может ещё что-то "сломается"...). оно конечно же можно и ручками дрова прикрутить, потом, вспомнив, что надо доставить пакеты "kernel-source", "kernel-syms", "linux-kernel-headers", "gcc", "make" и напечатав "init 3" в строке логина. а первым делом забэкапьте и обнулите "/etc/zypp/locks" файл! какого буя об этом молчат "известные собаководы" - непонятно...
sudo cp /etc/zypp/locks /etc/zypp/locks.old
su
(введите Ваш рутовый пароль)
echo "" > /etc/zypp/locks
exit
после чего ещё раз проверьте новые репо и давите на педальку:
sudo zypper ref && sudo zypper dup
как только безобразие закончится - не спешите в ребут. если вам нужно поставить драйвер ATI/NVIDIA - убедитесь, что как минимум стоят упомянутые выше пакеты. также можно до перезагрузки открыть YaST -> Software Management и установить все апдейты, которые он предложит. перегружаемся. если надо ставить дрова - уходим в "init 3" и ставим. возвращаемся в "init 5" и оцениваем "масштаб катастрофы". на первый взбляд всё будет тип-топ. новое ядро, типа новые пакеты, новая система... сверху - шоколадка, а внутри - кокос. сразу было сладко, а теперь приступим к изучению того, что нам оставила команда "zypper dup".
* мантра первая: если вы были уверены в том, что имеете полное право собирать программы из исходников и устанавливать их при помощи "sudo make install" - с результатами разбирайтесь сами. это подтолкнёт вас к изучению формата rpm и написанию кошерных spec файлов в будущем...
* мантра вторая: "не ссы, прорвёмся". всё на самом деле не так уж и плохо, скорее даже наоборот.
* мантра третья: думай своей головой. если с чем-то не согласен и это у тебя работает - есть смысл так и оставить.
* мантра четвёртая:
"Жаль, подмога не пришла
Подкрепленья не прислали
Нас осталось только два
Нас с тобою наебали..."
/БГ/
чтобы в этом убедиться далеко ходить не надо. выполняем команды:
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
результат нам покажет сколько пакетов осталось в системе от старой версии. но это не всё.
export OLD_VERSION="(none)"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
это покажет сколько пакетов имеют сомнительное происхождение. может вы собирали их сами, может ставили хз откуда - всё надо перепроверить. осмелюсь предложить вариант.
cd /tmp
rpm -qai > ./packages1
less ./packages1
находим по шаблону "11.0" старый пакет, смотрим как оно называется и рисуем (с правами рута!):
export pac="zsnes llvm llvm-devel" && rpm -e --nodeps $pac ; zypper in $pac
вот таким вот нехитрым макаром надо пройтись по всем пакетам и добиться, чтобы
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
в результате в системе не осталось следов от старой версии. с export OLD_VERSION="(none)" проще. в данном случае большинство пакетов есть не что иное как ключи шифрования. оставить их или убрать зависит от Вас и вашего поведения. обращайте внимание на все сообщения при
export pac="PACKAGES" && rpm -e --nodeps $pac ; zypper in $pac
это очень важно! например:
export pac="libx264-60" && rpm -e --nodeps $pac ; zypper in $pac
команда просто удалит x264 бинарь из вашей новой системы и напишет, что для версии 11.1 такого пакета (libx264-60) нет. и правильно, ибо есть пакет/ы libx264-67 и libx264-65! то есть вам надо после сообщения, что "пакет типа не найден нихуя" нарисовать в консоли
sudo zypper se libx264
и посмотреть на "варианты". дело это довольно муторное, должен признать. кроме того есть "нюансы" другого плана...
предположим, что Вы питаете нежную любовь к дивному "продукту" - Pulseaudio и, также как и я, не видите в нём никакого смысла. если в версии openSUSE-11.0 можно было извернуться и не ставить/(не запускать) это быдлоподелие, то в 11.1 без подобного "костыля" не запустится например "Stardict" и ряд других программ. кушать, так сказать, подано, Господа...
ну а в целом оно конечно же очень пиздато. перебил репы, нарисовал "zypper ref && zypper dup" и получил полный апгрейд! без проблем! во как!
*/
четверг, 12 марта 2009 г.
Too good to be true!
/*
Dear Ladies and Gents,
version "3.0.6" of openSUSE-Enlightenment (SOAD project) is out:
Download page
GWDG mirror will be updated to the version "3.0.6" on Monday (next week).
Changelog from 3.0.5 to 3.0.6 version
* new updated kernel (version 2.6.27.19_3.2)
* updated EFL/E to svn_r39423 (20090309)
* updated OOo (version 3.0.1.3)
* fixed "Del" key operation in "xterm"
* "aircrack-ng" added with extended set of documentation (look into "/usr/share/doc/")
* fixed the segfault during the first login to Enlightenment-DR17
* improved "Wicd" init script
* added GTK+ "Unity" theme
* removed "atl1e" driver for "Attansic" LAN cards (found on the eeepc1000* mostly)
* following drivers are added: "rtl8187", "rt73", "rt61", "r8101", "r8168"
* improved list of a default installed repositories
* overall code/software/packages update to the current openSUSE-11.1 state
* other misc. enhancements
In general - this version just works. The only disadvantage is that "LiveCD" version require 800M media (or a blank DVD-R/RW disk) and cannot be recorded to the standard 700M CD-R/RW. The absence of a "delta" images are due to the huge update of a packages - "delta" just has no sense this time.
We're also recommend you to visit our two new modest wiki pages and read a bit about:
Ecomorph
Wicd
Btw, it looks like "Wicd" have a chance to be a default network configuration tool for KDE-4.3 (Dev. Team are constantly improving the package, that's great!).
LiveCD: list of installed packages
USB-stick: list of installed packages
Huge thanks to Mikhail Kazakov for a help in preparation of this release version!
Enjoy!
P.S. The curious persons are welcome to glimpse at the small "Detailed uncompressed LiveCD packages size" pdf file.
Дамы и Господа,
версия "3.0.6" проекта SOAD доступна для Пользователей:
Страница загрузки
Простите, что LiveCD не уложился в 700Mb - новое ядро + жестокий падейт драйверов для звуковых карт никак не позволяет ввернуть Продукт в милый сердцу объём (0.7 на рыло). Вот вам расклад, как мы докатились до жизни такой.
"А в очтальном, прекрасная Маркиза, всё хорошо! Всё хо-ро-шо!" (Утёсов).
Так что пользуйте флешки. Для установки SOAD нужна флеха "объёмом" от 1-го Gb (эт копьё) и более.
Огромное СПАСИБО Михаилу Казакову за помощь в подготовке этого релиза!
Удачи!
*/
Dear Ladies and Gents,
version "3.0.6" of openSUSE-Enlightenment (SOAD project) is out:
Download page
GWDG mirror will be updated to the version "3.0.6" on Monday (next week).
Changelog from 3.0.5 to 3.0.6 version
* new updated kernel (version 2.6.27.19_3.2)
* updated EFL/E to svn_r39423 (20090309)
* updated OOo (version 3.0.1.3)
* fixed "Del" key operation in "xterm"
* "aircrack-ng" added with extended set of documentation (look into "/usr/share/doc/")
* fixed the segfault during the first login to Enlightenment-DR17
* improved "Wicd" init script
* added GTK+ "Unity" theme
* removed "atl1e" driver for "Attansic" LAN cards (found on the eeepc1000* mostly)
* following drivers are added: "rtl8187", "rt73", "rt61", "r8101", "r8168"
* improved list of a default installed repositories
* overall code/software/packages update to the current openSUSE-11.1 state
* other misc. enhancements
In general - this version just works. The only disadvantage is that "LiveCD" version require 800M media (or a blank DVD-R/RW disk) and cannot be recorded to the standard 700M CD-R/RW. The absence of a "delta" images are due to the huge update of a packages - "delta" just has no sense this time.
We're also recommend you to visit our two new modest wiki pages and read a bit about:
Ecomorph
Wicd
Btw, it looks like "Wicd" have a chance to be a default network configuration tool for KDE-4.3 (Dev. Team are constantly improving the package, that's great!).
LiveCD: list of installed packages
USB-stick: list of installed packages
Huge thanks to Mikhail Kazakov for a help in preparation of this release version!
Enjoy!
P.S. The curious persons are welcome to glimpse at the small "Detailed uncompressed LiveCD packages size" pdf file.
***********************************************
Дамы и Господа,
версия "3.0.6" проекта SOAD доступна для Пользователей:
Страница загрузки
Простите, что LiveCD не уложился в 700Mb - новое ядро + жестокий падейт драйверов для звуковых карт никак не позволяет ввернуть Продукт в милый сердцу объём (0.7 на рыло). Вот вам расклад, как мы докатились до жизни такой.
"А в очтальном, прекрасная Маркиза, всё хорошо! Всё хо-ро-шо!" (Утёсов).
Так что пользуйте флешки. Для установки SOAD нужна флеха "объёмом" от 1-го Gb (эт копьё) и более.
Огромное СПАСИБО Михаилу Казакову за помощь в подготовке этого релиза!
Удачи!
*/
Подписаться на:
Сообщения (Atom)
