ArchLinux предполагает наличие файлов .PKGINFO и .FILELIST в пакете. Думаю, их должен делать alien, обладая специальной поддержкой pacman.
.PKGINFO генерируется утилитой makepkg при построении пакета с помощью PKGBUILD. Как делать их с помощью pacman'а и alien'а - не понимаю. Я сделал пакет дял Archa'a руками. Для получения .FILELIST написал скрипт. Есть файл .PKGINFO, но непонятно, как получить для него параметр size. Пока нету ArchLinux'a с рабочим pacman'ом, чтобы проверять, ставится ли пакет локально.
(In reply to comment #1) > .PKGINFO генерируется утилитой makepkg при > построении пакета с помощью PKGBUILD. > Как делать их с помощью pacman'а и alien'а - не > понимаю. Да, вручную, а как ещё. > Я сделал пакет дял Archa'a руками. Для > получения .FILELIST написал скрипт. Есть файл > .PKGINFO, но непонятно, как получить для него > параметр size. Ну так надо на примере какого-то пакета понять что есть size, и насколько он важен. Мне кажется это распакованный размер.
>Ну так надо на примере какого-то пакета >понять что есть size, и насколько он важен. >Мне кажется это распакованный размер. В том то и дело, что непонятно, что это такое. делал так: [root@builder pkgdata]# tar xvf ../pkgdata-0.61.1-1.pkg.tar.gz [root@builder pkgdata]# du -sk | awk '{print $1 * 1024}' 15192064 И так: [root@builder ~]# du -sk pkgdata-0.61.1-1.pkg.tar.gz | awk '{print $1 * 1024}' 4317184 В .PKGINFO: size = 4900175 du -sk | awk '{print $1 * 1024}' взял из скрпита makepkg. Важность его и хочу выяснить, попробовав поставить локально пакет pacman'ом. Но в чруте pacman нерабочий.
Ставится и без size. Но в базе pacman'а его нет. Так выглядит мой .PKGINFO: # Generated by makepkg 3.0.3 # Wed Sep 19 20:48:49 CEST 2007 pkgname = wine pkgver = 1.0.8 pkgdesc="Emulator of the Windows 3.x and Win32 APIs" url="http://www.winehq.com" builddate = Wed Sep 19 18:48:49 2007 packager = Yuri Fil <yurifil@altlinux.org> arch = noarch license = GPL license = LGPL depend = fontconfig depend = libldap depend = libxslt depend = lcms depend = libxxf86dga depend = libxcursor depend = libxrandr depend = libxdamage depend = freeglut В системе: pacman -Qs wine error: invalid name for database entry 'wine-1.0.8' pacman -Qs wine-1.0.8 error: invalid name for database entry 'wine-1.0.8'
Что интересно, в оригинальном вайне нет файла .FILELIST. Как восстановят Арч, нужно будет попробовать собрать пакет без этого файла.
Без .FILELIST тоже самое происходит: установить пэкмэном удается, но в базе пэкмэна нет: pacman -Q wine error: invalid name for database entry 'wine-1.0.8' error: package "wine" not found Не могу понять, в чем проблема: вроде, .PKGINFO сделан как в арчевском вайне.
надо ускорить процесс...
Зарегестрировался на форуме ArchLinux. Может, там разъяснят, как паковать бинарники.
Как починят testing, попробую собрать с помощью abs.
Что-нибудь проясняется?
Ау?
Руками добавить файлы не получилось. Собрал в Арче пакет. Если можно как-то выложить файл из системы на ftp, то, в целом, задача решена. Почти готов скрипт, которым можно будет собирать под Арч разные пакеты. Осталось разобраться с владельцами каталогов.
Готово.
Если делать конвертор, он должен добавлять в архив файл .PKGINFO, файл wine.outformat и скрипт wine.
Created attachment 955 [details] скрипт wine
Created attachment 956 [details] wine.outformat
(In reply to comment #14) > Если делать конвертор, он должен добавлять > в архив файл .PKGINFO, файл wine.outformat и скрипт wine. > Скрипты wine.outformat и wine ставятся чрез make install, что можно увидеть в любом спеке wine. Так что осталось разобраться в отличиях .PKGINFO.
Файл PKGINFO можно добавлять так: копировать сделанный alien'ом тарбол в систему, распаковывать его, упаковывать бинарники с помощью abs, как и предополагалось ранее.
Но в этом случае непонятно, как быть с wine*
(In reply to comment #18) > Файл PKGINFO можно добавлять так: > копировать сделанный alien'ом тарбол в > систему, распаковывать его, упаковывать > бинарники с помощью abs, как и > предополагалось ранее. Возможно alien можно установить прямо в Arch, что упростит процедуру.
Не совсем понимаю, какой смысл ставить алиен в Арч, если после конвертации получается нерабочий пакет.
Надо сделать скрипт, который будет вставлять в "черновой" пкгбилд данные о пакете. Плюс, как-то зависимости приводить к Арчевским (они в PKGINFO есть). Потом копировать пкгбилд и архив с бинарниками в Арч и пересобирать пакет. Есть другие варианты?
http://aur.archlinux.org/packages.php?ID=3710 http://bbs.archlinux.org/viewtopic.php?id=48573 ещё есть rpmextract http://unixforum.org/index.php?s=c2fa35d81f2890a84d202846d8caadac&showtopic=52902&pid=524482&mode=threaded&start=#entry524482 Для проверки получившегося пакета надо использовать не клиентов, а namcap
Не могу пока сообразить, откуда брать версию, релиз, url и тип лицензии для добавления в pkgbuild. Видимо, нужно как-то извлекать их из спеков собираемых пакетов.
(In reply to comment #24) > Не могу пока сообразить, откуда брать > версию, релиз, url и тип лицензии для > добавления в pkgbuild. Видимо, нужно как-то > извлекать их из спеков собираемых пакетов. Открой для себя нечто типа rpmquery --queryformat "%NAME = %VERSION" пакет
Готов скрипт, конвертирующий rpm в pkg.tgz. Осталось разобраться, куда в сборочную систему его вставлять.
Похоже, следует заменить скриптом alien в функции convert_rpm() из build-rpm.sh.
В этом случае надо либо чтобы скрипт находился в системе (например, поставлялся в составе etersoft-build-utils) или копировать его во время сборки (как в gentoo).
(In reply to comment #28) > В этом случае надо либо чтобы скрипт > находился в системе (например, поставлялся > в составе etersoft-build-utils) или копировать его во > время сборки (как в gentoo). Ну вполне можно копировать во время сборки.
Готова рабочая версия. Закоммитил. Теперь нужно разобраться с добавлением зависимостей и регистрационных номеров для закрытых частей.
В теперешнем варианте добавлена case-ветка в build-main.sh: собираются rpm, в BUILDROOT копируется скрипт convert_to_pkg_tgz, с его помощью rpm конвертируются в pkg.tar.gz. Получился гибрид сборки для Gentoo и rpm-дистрибутивов. Можно попробовать сделать как предполагалось ранее - заменить alien в build-rpm. В этом случае, видимо, нужно, чтобы скрипт (convert_to...) лежал в системе постоянно.
Скрипт готов. Можно закрывать багу?
