мениджър на пакети opkg
Пътека на гребла и велосипеди
Преди много години, когато бях инженер в малка фабрика, когато стартирах Linux на първата носна кърпичка от собственото си производство, инсталирах всички необходими пакети от отдалечено хранилище с помощта на opkg, конфигурирах всички приложения, ръководителят на лабораторията каза: „Страхотно! Сега направете същото на всички устройства в партидата.“ "Разбира се, не е проблем!" Отговорих. Системата е там, работи, работи. Копираме всички файлове от корена на външно устройство, след което го пакетираме в изображение и се наслаждаваме на живота! По това време не разбрах, че по време на работа операционната система извършва редица локални настройки, създава временни файлове, конфигурационни файлове, генерира някои ключове и също така изпълнява скриптове за инициализация при първото стартиране. Въпреки че прехвърлянето на файлове от една работеща система в друга с помощта на метода на грубо копиране от носители свърши работа, ефективността на този метод много скоро стана съмнителна за мен. Невъзможно е да се получи "чиста" система по този начин: системата помни предишния си живот в друго хардуерно тяло и от време на време се задушава от фантомни болки.
Следващата стъпка за мен беше разбирането на структурата на самия пакет*.ipk. По същество пакетътipk е архив, който може лесно да бъде разопакован с помощта на командата:
В резултат на това получаваме:
Архивът data.tar.gz съдържа файлове, които трябва да бъдат поставени в основната директория на целта. Архивът control.tar.gz съдържа сервизни файлове: файл с описание и скриптове. Идеята е проста: тъй катоipk е просто архив със скриптове, винаги можем ръчно да го разархивираме в директория с файловата система и след това да го стартираме (ако има такъв в тованужда) скриптове. Но ще трябва да инсталираме и всички зависимости на пакета ръчно. Ами ако зависимостите имат други зависимости? Възниква идея, може би да напиша скрипт за автоматизиране на процеса? Както често се случва в света на Linux, ако имате задача пред вас, тогава най-вероятно такава задача не е възникнала само пред вас и най-вероятно не сте първият в този бизнес. Не трябваше да ходим далеч, всъщност самият мениджър на пакети opkg има режим, при който пакетите се инсталират на неактивната файлова система rootfs. В същото време архитектурата на хост машината (където се изпълняват помощните програми opkg) и целевите машини могат да бъдат различни. Този режим се наричаОфлайн режим. В този режим opkg се превръща в мощен инструмент за кръстосано развитие.
Изграждане на opkg за хост
За да работи в режимОфлайн, opkg трябва да се изпълнява на хоста. От дълго време Ubuntu се настани на моя работен компютър (сега е инсталиран Ubuntu 14.04 LTS) и ние ще изградим нашия инструментариум върху него. Не можах да намеря хранилище с opkg за Ubuntu, така че изграждаме набор от помощни програми от източниците. Можете да получите изходните кодове от git хранилището на проекта Yocto:
Всъщност настройката и компилирането на проекта се извършва по доста стандартен начин, но има някои нюанси и следователно всичко е наред. Изпълни:
Забележка: ако стартирате ./autogen.sh с опцията --clean, тогава цялата работа по конфигурацията на проекта ще бъде изтрита. След изпълнение на ./autogen.sh скриптът за конфигуриране се появява в изходната директория, той ще конфигурира пакета, ще определи и зададе зависими от системата променливи. В резултат на скрипта се създава Makefile. Можете да видите всички опции на скрипта по стандартния начин:
Ще съберем пакета за текущата платформа, тъй като опциитепропуснете настройките за кръстосана компилация. Да се погрижим за монтажа. По подразбиране, като стартира make install, скриптът ще разпръсне всички полезни файлове (двоични файлове, скриптове, документация) в основната директория: /etc, /usr/local и това е напълно безполезно за нас. Няма да използваме opkg за настройка на пакети в текущата система, нали? Освен това, като инсталирате мениджъра в системни папки, ще ви трябват права на суперпотребител, за да използвате помощните програми, според мен това е излишно при настройване на вградено изображение на Linux. Скриптът configure.sh ви позволява да зададете префикс за инсталационната директория на пакет. Като посочим която и да е работна директория като префикс, ние ще кажем на инсталатора къде да инсталира пакета. Ако е необходимо, можете отделно да зададете префикс за зависещи от архитектурата (двоични файлове и библиотеки) и независими от архитектурата (скриптове и документация) файлове. Винаги съм имал малко въображение, така че за инсталиране в домашната директория ще създадем директорията opkg_offline.
При необходимост доставяме необходимите зависимости. Така че на Ubuntu 14.04 трябваше да доставя libarchive-dev, libcurl4-gnutls-dev, libssl-dev, libgpgme11-dev, за да компилирам успешно.
Компилирайте и инсталирайте opkg:
Мениджърът на пакети е компилиран и инсталиран. Изпълнимите файлове се намират в директорията opkg_offline/bin. За да работите с тях, можете да зададете пътя към променливата PATH, или да извикате експорт ( експорт ) за всяка терминална сесия, или да направите като мен - отидете в директорията opkg_offline и стартирайте директно ./bin/opkg.
Кратък курс по анатомия
Нека да разгледаме набързо как работи мениджърът на пакети в стандартен режим. След изпълнение на командата opkg update, помощната програма чете конфигурационните файлове, които по подразбиране се намират в /etc/opkg и имат разширение .conf. От тези файлове систематаопределя вида на архитектурата, например armv5hf-vfp или armv5tehf-vfp (може да има няколко поддържани архитектури, на всяка може да се даде приоритет), списък с хранилища и някои настройки за самата програма. След това за всяко хранилище от списъка се изтегля архив от тип *_Packages.gz. Архивите се поставят в директорията var/cache/opkg/ по подразбиране. След разопаковането, съдържанието се поставя във var/lib/opkg/lists. Всеки архив съдържа текстов файл със списък на пакетите в хранилището. За всеки пакет, в допълнение към името, са посочени версията, архитектурата, размерът, краткото описание, лицензът и най-важното - зависимостите. Въз основа на тези файлове мениджърът на пакети може при поискване да предостави информация за необходимия пакет и при инсталирането му да определи всички зависимости и да ги разреши. Командата opkg list ще изведе всички налични пакети за инсталиране; командата opkg list-installed ще покаже само инсталираните пакети, командата opkg info ще покаже информация за посочения пакет и, ако е инсталиран, времето за инсталиране. За да инсталирате пакет, изпълнете opkg install packname. В резултат на това необходимият пакет от хранилището ще бъде изтеглен във временна директория и разопакован. Всички файлове от архива data.tar.gz ще отидат на местата си в rootfs и въз основа на съдържанието на control.tar.gz ще бъдат създадени сервизни файлове в директорията var/lib/opkg/info: packname.control - пълна информация за пакета, packname.list - списък с директории, където са били разпространени файловете от data.tar.gz (opkg ще премине през този списък, когато пакетът бъде изтрит) и скриптови файлове, като packname.postin st, packname.preinst, packname.prerm, packname.postrm, чиято цел е ясна от името. Информацията за инсталирания пакет ще бъде добавена към файла var/lib/opkg/status във формата (пример за популярния minicom):
Важно е да се плативнимание на статуса. Ако пакетът е инсталиран според всички правила: всички файлове са копирани на мястото им, всички скриптове са изпълнени, тогава състоянието ще бъде Статус: инсталиране добре инсталирано. Когато работите офлайн, всички файлове ще бъдат копирани, но скриптовете няма да бъдат изпълнени, такива пакети ще бъдат маркирани като Status: install ok unpacked . В този случай opkg предоставя специален механизъм за постконфигуриране на пакети. Стартира се с командата opkg configure
. Ако посочите името на конкретен пакет, тогава ще бъдат изпълнени скриптове от var/lib/opkg/info за този пакет; ако името е пропуснато, тогава мениджърът ще конфигурира всички пакети, които имат Status: install ok unpacked . По този начин, когато инсталирате пакети на хост в офлайн режим, първия път, когато стартирате операционната система на целта, трябва да изпълните opkg configure. Можете да поверите това или на специален скрипт, или, ако се използваsystemd, на специална услуга.
Справяне с целеви rootfs
Време е да изпробвате системата в действие. Например, нека инсталираме терминалния емулатор на сериен порт minicom. За да инсталираме пакетите, имаме нужда от разопаковано изображение на главната файлова система на целевата рамка на rootfs. Да приемем, че opkg мениджърът е инсталиран в rootfs и има *.conf конфигурационни файлове в etc/opkg директорията. Ако не е там или по някаква причина не искаме да използваме конфигурацията от rootfs, можем да посочим кой конфигурационен файл да използваме чрез параметъра: -f etc/opkg/opkg.conf. Предаваме пътя до целевата файлова система чрез параметъра --offline-root /path/to/rootfs. Актуализиране на списъци с пакети:
Преглеждаме списъка с налични пакети, търсим minicom.
Вижте информацията за пакета:
Във файла var/lib/opkg се появи запис:
Веднъж създаденизображение, системата е стартирана и е изпълнена командата opkg configure, записът във файла е променен:
Тъй като персонализираният rootfs е за вградена машина, крайният размер на изображението има значение. Затова препоръчвам, след като са инсталирани всички необходими пакети, да изтриете изтеглените списъци и да изчистите кеша:
Забележка: Опцията --volatile-cache ще изчисти кеша автоматично при изключване.