Packaging Automation/Импорт Пакетов из других дистрибутивов
Введение.
В системах автоматизации за преобразование пакетов отвечают утилиты, использующие набор плагинов к библиотеке RPM::Source::Transform из в пакета perl-RPM-Source-Convert.
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 вычислять пока не обучен и для робота кусок вида
- 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.
> но тут явно нельзя заменять их %cmake на наш, он просто ломает всю сборку ;-) > если только написать свой какой-то %cmake_fs,
Руслан, вы попали в точку. в fcmass действительно fs %cmake меняется на %cmake_fedora поэтому, по идее, c mytrinitymass-fc получится собирающийся tdelibs.
а вот в susemass такой подстановки нет, не дошли руки. Надо сделать. Пока попробуйте tdelibs сгенерировать с помощью mytrinitymass-fc. Igor Vlasenko <ivlasenko@gmail.com>
Oct 29 (2 days ago)
to Хихин 2016-10-29 11:50 GMT+03:00 Igor Vlasenko <ivlasenko@gmail.com>: > в fcmass действительно fs %cmake меняется на %cmake_fedora и вставляется BR: rpm-macros-fedora-compat, конечно.
> Вот эти строки в tqt3 похоже надо удалять из спека, получаемого из Suse
> %suse_update_desktop_file tqassistant Documentation
> %suse_update_desktop_file tqdesigner GUIDesigner
> %suse_update_desktop_file tqlinguist Translation
> %suse_update_desktop_file tqtconfig Utility
нет, это все хорошие строки. их робот конвертер вписал. Просто установите в host систему пакет rpm-macros-suse-compat.
INFO: SourceAnalyzer: nothing in devel-libs provides wtc8.
INFO: SourceAnalyzer: nothing in devel-libs provides pm.
grep по исходникам сказал что wtc8 это only Oracle 8
./src/sql/qt_sql.pri: LIBS += -lclntsh -lwtc8 ./configure: OCI_REQ="-lclntsh -lwtc8 oci.h" ./doc/sql-driver.doc:\i \c libwtc8.so (only Oracle 8) or \c libwtc9.so (only Oracle 9) ./doc/sql-driver.doc:qmake -o Makefile "INCLUDEPATH+=$ORACLE_HOME/rdbms/public $ORACLE_HOME/rdbms/demo" "LIBS+=-L$ORACLE_HOME/lib -lclntsh -lwtc8" oci.pro
./doc/html/sql-driver.html: