Показаны сообщения с ярлыком rpm. Показать все сообщения
Показаны сообщения с ярлыком rpm. Показать все сообщения

четверг, 30 октября 2008 г.

Явное указание архитектуры процессора при сборке RPM

Если мы компилим rpm пакеты из SRPM, то почему бы не убить двух зайцев сразу - и не оптимизировать пакеты под свой процессор (если, конечно, машина не крутится на стареньком i586). Описываемый ниже спсоб не страдает элегантностью, но он, по крайней мере, работал на Mandriva 2008.1
Наша задача разбивается на два этапа (в приведенных далее командах предполагается что пакет собирается для архитектуры pentium4 - доступные значения архитектуры можно смотреть в man gcc (1) (значения опций -march и -mtune) или в файле /usr/lib/rpm/rpmrc - там нам интересны значения arch_canon):
  1. для компиляции пакета для нужной целевой платформы в строку вызова rpmbuild добавляем опцию --target=pentium4
  2. пакет-то мы на прошлом шаге собрали, только rpm -i не сможет его установить. Побеждется это записью строки pentium4-intel-linux (или как там правильно для Вашей архитектуры) в файл /etc/rpm/platform

вторник, 16 сентября 2008 г.

Обновление приложений во FreeBSD и в CentOS



Старая как мир задача - что-то где-то обновилось (напр. clamav), нужно броситься вдогонку за новой версией. Что делаем? (только pls не ищите ниже очередного гундения на тему, что круче - линух или фря - это просто записки на память) Версии систем у меня такие: FreeBSD 7.0 и CentOS 5.2.
FreeBSD
  • Если нет никакого еще дерева портов (это кажется не наш случай, но на всякий пожарный), то # portsnap fetch extract update;
  • Если уже запускался ранее portsnap(8) (искать его следы в /var/db/portsnap - если командой portsnap не пользовались, то он будет пустой), то # portsnap fetch update;
  • Если есть старое дерево портов и supfile для портов (болванку брать в /usr/share/examples/cvsup/ports-supfile), то # csup ports-supfile;
Потом:
# cd /usr/ports/dir/ourport
# make deinstall reinstall clean
Если какие-то пакеты зависят от нашего, make reinstall не обращает на это никакого внимания, толтко сообщает о несчастных в консоль (чтобы потом не забыли похоронить трупы и эвакуировать выживших ;)
Если обновляли демона - не забыть:
# /usr/local/etc/rc.d/ourdaemon restart
и смотреть в логи на результаты
CentOS
Ищем где-нибудь на просторах инета нужный src.rpm (допустимые платформы rhel или centos - желательно, fc - фопустимо, с mdv и suse лучше не связываться). Для начала можно попробовать поискать на офинциальных зеркалах - напр. тут, но там мало чего есть. Порой помогает rpmfind или сайты приложений). Допустим, нашли:
# rpm -i myprog.src.rpm
# cd /usr/src/redhat/SPECS
ищем specfile нашего приложения - и нещадно правим. Потом:
# rpmbuild -bb myprog.spec
установочный пакадж образуется в папке ../RPMS/arch (arch может быть noarch, i386, i586 и т. д.), его и ставим:
# rpm -U ../RPMS/myarch/myprog.rpm
Если это был демон, перзапускаем:
# /etc/init.d/mydaemon restart
и тоже идем читать логи ;)
Удалить srpm, если исходники уже не нужны, можно командой:
# rpmbuild --rmsource myprog.spec