Packaging Automation/Импорт Пакетов из других дистрибутивов: различия между версиями

Материал из ALT Linux Wiki
(Новая страница: «__TOC__ === Введение. === В системах автоматизации за преобразование пакетов отвечают утилиты, ...»)
 
Строка 4: Строка 4:


В системах автоматизации за преобразование пакетов отвечают утилиты,
В системах автоматизации за преобразование пакетов отвечают утилиты,
использующие  набор плагинов к библиотеке {{pkg|RPM::Source::Transform}} из в пакета {{pkg|perl-RPM-Source-Convert}}).
использующие  набор плагинов к библиотеке {{pkg|RPM::Source::Transform}} из в пакета {{pkg|perl-RPM-Source-Convert}}.




{{Stub}}
{{Stub}}


TODO
== TODO ==


Это потому, что qr'' -- вид кавычек, для regexp.
Это потому, что qr'' -- вид кавычек, для regexp.
Строка 193: Строка 193:
и пакет прошел в Сизиф.
и пакет прошел в Сизиф.
утилита girar-print-build-commit из пакета girar-nmu.
утилита girar-print-build-commit из пакета girar-nmu.


=== Базовые утилиты ===
=== Базовые утилиты ===

Версия от 21:06, 31 октября 2016

Введение.

В системах автоматизации за преобразование пакетов отвечают утилиты, использующие набор плагинов к библиотеке RPM::Source::Transform из в пакета perl-RPM-Source-Convert.


Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.


TODO

Это потому, что qr -- вид кавычек, для regexp.

надо $spec->get_section('install',)->subst_body ( gr'\{_datadir\}/icons', '_niconsdir' );


> А просто > $spec->get_section('install',)->subst_body('\{_datadir\}/icons','_niconsdir'); > проходит да. но правильнее брать в qr' ' , она лучше дружит с регулярными выражениями.


2016-10-23 20:34 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>: > Здравствуйте Igor Vlasenko > Есть смысл добавить некоторые зависимости, которых нет в suse. > Это только через "патчи", или есть ещё какой-нибудь хитрый приём?

я использую скрипты по умолчанию --hooks/<имя пакета>.pl это удобно тем, что вся информация, что в пакете вносилось руками, собрана в одном месте.

есть и другие способы, например, flags/add_buildreq.txt см. мой perl-package-builder.git но потом в итоге можно запутаться.


если какие хаки вносятся во все пакеты, то их надо явно вносить руками. я обычно делаю скрипт обертку, в который вписываю явно вызовы этих хаков которые для всех пакетов. к примеру trinnitymass --такой скрипт обертка. посмотрите в mate есть похожий скрипт обертка matemass и внутри явно грузится --hook ./mate.pl



2016-10-23 21:18 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>: > Здравствуйте Igor Vlasenko > В сообщении от 23 октября 2016 вы написали: > > Слишком маленькая версия suse получается. Должно быть что-то типа > 1320, а нас 1150. Это где лучше/правильнее подкручивать?

У меня в RPM/Source/Convert/Plugins/SuSE2ALT.pm отстал от жизни - давно с suse пакетами не ковырялся.

new task #171277: owner=viy repo=sisyphus task #171277: added #100: build srpm perl-RPM-Source-Convert-0.618-alt1.src.rpm task #171277: try #1 is AWAITING, result will be emailed to viy@altlinux.org

0.618-alt1 - bumped suse version to 1320 thnx to Ruslan Hihin



Ой, то-что внизу -- это если rpmbuild -bs завершился неудачей, то распакованный srpm не удаляется, чтобы можно было внутри посмотреть, почему так. все, что в листинге -- мусор, аналог crush dump.

drwxr-xr-x - fileshareset-2.0-1.fc23.15605 tree | history drwxr-xr-x - fileshareset-2.0-1.fc23.15852 tree | history drwxr-xr-x - trinity-abakus-0.91-14.0.3_1.fc23.14567 tree | history drwxr-xr-x - trinity-akode-2.0.2-14.0.3_1.fc23.14567 tree | history drwxr-xr-x - trinity-amarok-1.4.10-14.0.3_1.fc23.14567 tree | history drwxr-xr-x - trinity-arts-1.5.10-14.0.3_1.fc23.14567 tree | history drwxr-xr-x - trinity-avahi-tqt-0.6.30-14.0.3_1.fc23.14567 tree | history drwxr-xr-x - trinity-basket-1.0.3.1-14.0.3_1.fc23.14567 tree | history


зашел в распакованный подкаталог и сделал

rpmbuild -bs --nodeps --define '_sourcedir ./SOURCES' ./SPECS/*.spec

получил src.rpm.


> А вот такой вопрос - есть файлы подстановок групп, а нет-ли > файлов подстановок пакетов? Что-бы я мог написать список для > подстановки, а скрипт из него сделал-бы подстановку (если он > неправильно сработал), ну а потом я мог-бы отослать список тебе, > что-бы он вошёл в основной пакет.

не совсем изящно, но: файлы подстановок пакетов -- это distromap. уже установленные пакеты distromap-fedora-rawhide-altlinux-sisyphus distromap-suse-default-altlinux-sisyphus не поправить, но distromap.обучено смотреть перед ними и в другие места.

соответственно, склонируйте distromap-fedora2alt.git (по фиксированному пути ~/src/repo/distromap-fedora2alt.git -- прибит гвоздями в perl-DistroMap :( если не удобно, можно придумать переменную, которая будет указывать) добавьте в папке binary свой txt файл trinity.txt с заменами и эти замены будут подхвачены на лету. а по итогам работы этот файл уйдет в сизифный пакет.

> И вот ещё - ведь теоретически наши пакеты могут быть раздробленны > на более мелкие кусочки, чем в suse/федора, и вместо отношения > один к одному, мы можем иметь случай один к нескольким, и тогда, > наверное надо для таких случаев писать, что при сборке > пакета "z" надо сделать подстановку "a" на пакет "A", а при > сборке пакета "y", "a"->"B", или "a"->"A,B". > Как в этом случае предусмотренно (пока такого у меня не было, но > хотелось-бы знать заранее) ?

там именно такой формат в файлах. замена a -> A B C ... список соединяем пробельными символами, получим a A B C ...



Гм. там беда, что distromap то знает правильные подстановки, см. grep -r nas-devel /usr/share/distromap/fedora/rawhide/altlinux/sisyphus/binary binary/40-distrodb.txt:nas-devel libaudio-devel

но имена пакетов сунуты в макрос, а робот уповат и %if вычислять пока не обучен и для робота кусок вида

  1. LIBAUDIO support

%if 0%{?fedora} || 0%{?mgaversion} || 0%{?mdkversion} || 0%{?alt_version} || 0%{?suse_version} && 0%{?opensuse_bs} == 0 %define with_nas 1 %if 0%{?fedora} || 0%{?mgaversion} || 0%{?mdkversion} %define libaudio_devel nas-devel %endif %if 0%{?suse_version} && 0%{?opensuse_bs} == 0 %define libaudio_devel libaudio-devel %endif %if 0%{?alt_version} %define libaudio_devel libaudio-devel %endif %endif выглядит просто как %define libaudio_devel nas-devel %define libaudio_devel libaudio-devel %define libaudio_devel libaudio-devel и в итоге внутри робота %define libaudio_devel libaudio-devel.

Если в спеках %define для suse всегда последние, что надо еще проверить, то да, susemass.

Если же за fedora держаться, то надо будет предобработку спеков, чтобы предвычислить %if и убрать лишние %if %else %endif вместе с ненужными вариантами.



>> Пример как снять git-inheritance с пакета, который заливался >> как gear, а потом залит как srpm: >> ssh girar task check-git-inheritance 169825 100 disable >> `girar-print-build-commit -b sisyphus >> perl-Data-Validate-Domain` > Это поподробнее, если можно, хотелось-бы понять, что эти команды > делают. Но если время нет, то я потом сам разбурусь.

Это из реальной жизни. Залил как-то в Сизиф обновление perl-Data-Validate-Domain как srpm (майнтайнеры мне perl отдали) а сборочница не пустила. говорит, git-inheritance, не пущу, пакет ранее был залит с git .gear репозитория. Это был task 169825 subtask 100. я выполнил волшебную команду $ ssh girar task check-git-inheritance 169825 100 disable `girar-print-build-commit -b sisyphus perl-Data-Validate-Domain` затем $ ssh girar task run 169825 и пакет прошел в Сизиф. утилита girar-print-build-commit из пакета girar-nmu.

Базовые утилиты