Представлен (http://giftwrap.tuxfamily.org/) первый релиз GiftWrap, GUI-интерфейс для упрощения создания пакетов для Ubuntu Linux, основанной на кодовой базе проекта Deb Creator (http://debcreator.cmsoft.net/). В настоящий момент поддерживается создание пакетов из набора исходных текстов с максимальной автоматизацией всех рутинных операций. В будущих версиях ожидается (http://giftwrap.wikia.com/wiki/Roadmap) возможность операций по модификации и обновлению содержимого пакетов, загрузке пакетов в PPA, разбиению пакета на части, автоформированию .desktop файлов и меню.URL: http://giftwrap.tuxfamily.org/
Новость: http://www.opennet.me/opennews/art.shtml?num=21951
Видео очень понравилось! Возможность легко создавать нормальные пакеты для дебиана и производных, это то, чего мне когда-то не хватало (до того как я мигрировал на арч :Р ). Ах да, про checkinstall я в курсе, но созданные им пакеты нормальными язык назвать не поворачивается.
По моему скромноиу мнению лучше slackbuild ничего нет.
Очнулись же, в CRUX и Arch уже давно есть хорошая система сборочных скриптов, писать эти скрипты - одно удовольствие
>Очнулись же, в CRUX и Arch уже давно есть хорошая система сборочных
>скриптов, писать эти скрипты - одно удовольствиеА какие в генту и фрибсд "системы сборочных скриптов" ! Вы закачаетесь просто :)
На самом деле я думал лучше будет, а так, маловменяемая чехарда
* http://repos.archlinux.org/viewvc.cgi/kdelibs/repos/extra-i6...
* http://gentoo-portage.com/AJAX/Ebuild/88333/View
* http://ecarux.de/ports/kdelibs/Pkgfile
И для полного счастья посмотрите фряшные порты. Потом и поговорим, а возможно кто-то и закачается
>И для полного счастья посмотрите фряшные порты.http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/kdelibs4/Mak...
Не поленился и нашёл сам.
>На самом деле я думал лучше будет, а так, маловменяемая чехарда
> * http://repos.archlinux.org/viewvc.cgi/kdelibs/repos/extra-i6...
> * http://gentoo-portage.com/AJAX/Ebuild/88333/View
> * http://ecarux.de/ports/kdelibs/Pkgfile
>И для полного счастья посмотрите фряшные порты. Потом и поговорим, а возможно
>кто-то и закачаетсяИ в чем плюсы PKGBUILD например перед EBUILD для kde-libs?
P.S. Предыдущего троля кормить не буду само собой, я жадный :)
>И в чем плюсы PKGBUILD например перед EBUILD для kde-libs?В простоте, очевидно. И тот и другой решают поставленную задачу - на выходе тёпленький пакет, который можно спокойно передавать пакетному менеджеру.
>>И в чем плюсы PKGBUILD например перед EBUILD для kde-libs?
>
>В простоте, очевидно. И тот и другой решают поставленную задачу - на
>выходе тёпленький пакет, который можно спокойно передавать пакетному менеджеру.Да? :) и какой в генту пакет на выходе и какой пакетный менеджер? :)
Я Арча в глаза не видел поэтому мне дико интересно, при вот таком вот виде зависимостей:
depends=('phonon' 'shared-mime-info' 'libxpm' 'hal'
'enchant' 'jasper' 'openexr' 'strigi' 'libxtst'
'giflib' 'soprano' 'ca-certificates' 'xdg-utils' 'libxft')
makedepends=('pkgconfig' 'cmake' 'automoc4' 'intltool' 'avahi' 'libgl' 'hspell')как вы решаете проблему если собираемому/собраному пакету нужны какие-то строго определенные (ну или не ниже) версии зависимостей?
>как вы решаете проблему если собираемому/собраному пакету нужны какие-то строго определенные (ну или не ниже) версии зависимостей?http://repos.archlinux.org/viewvc.cgi/xorg-server/repos/extr...
Удивительно сложное решение высосанной проблемы из пальца
>>как вы решаете проблему если собираемому/собраному пакету нужны какие-то строго определенные (ну или не ниже) версии зависимостей?
>
>http://repos.archlinux.org/viewvc.cgi/xorg-server/repos/extr...
>Удивительно сложное решение высосанной проблемы из пальцаВопрос про пакеты в генту вы проигнорировали и плавно перешли на XORG - уже теплее :)
Ну иксы так иксы :) А теперь продемонстируйте мне с помощью приведенного вами PKGBUILD сборку xorg-server с определенными input_device/video_cards или без hal? :)
А теперь вспоминайте о чём шла речь, о вменяемой и понятной системе. А собрать без хала проще простого, удаляете из depends 'hal>=0.5.11', а в теле build изменяете ключ у configure на --disable-config-hal. Всё.
>А теперь вспоминайте о чём шла речь, о вменяемой и понятной системе. А собрать без хала проще простого, удаляете из depends 'hal>=0.5.11', а в теле build изменяете ключ у configure на --disable-config-hal. Всё.Подразумевается что PKGBUILDы у вас тоже синкаются с неким центральным репо? И что будет с вашими фиксами при следующем синке?
С моими фиксами это дело лежит в /var/abs/local , когда всё остальное синкается в другие каталоги /var/abs/{extra,core,testing}
>С моими фиксами это дело лежит в /var/abs/local , когда всё остальное
>синкается в другие каталоги /var/abs/{extra,core,testing}Это понятно, переводя на понятный мне язык локальные оверлеи...
Наверное очень удобно при обновлении версии каждый раз патчить и переносить в local 50 пакетов где вам не нужен hal ? ;]
Хитрость том, что из 50 пакетов, для которых в optdepends есть к примеру тот же хал, используется на одной системе не больше 5-6 (а хал мне оказался ненужным только для xserver). Я же говорил, по существу собирается мной порядка пакетов 80, остальные (порядка 300) всё-таки устанавливаются пакманом в готовом виде из репозитария. Да и не помню, чтобы теплым летним вечером сразу же 80 пакетов обновились. Поддерживать эти 80 PKGBUILDов не составляет труда (обычно всё гладко проходить пересчётом хэшэй тарбола и изменением чисел в pkgver)
>Да? :) и какой в генту пакет на выходе и какой пакетный менеджер? :)Я Генту в глаза не видел, но всегда считал, что portage синкает дерево ебилдов и собирает абстрактный пакет, который дальше устанавливается абстрактным пакетным менеджером (мб и самим portage). А Арче пакет собирается makepkg и этот пакет ставиться пакетным менджером pacman. Но дела это не меняет
>>Да? :) и какой в генту пакет на выходе и какой пакетный менеджер? :)
>
>Я Генту в глаза не видел, но всегда считал, что portage синкает
>дерево ебилдов и собирает абстрактный пакет, который дальше устанавливается абстрактным пакетным
>менеджером (мб и самим portage). А Арче пакет собирается makepkg и
>этот пакет ставиться пакетным менджером pacman. Но дела это не меняет
>Только если sandbox очень абстрактный пакет :)))
>Только если sandbox очень абстрактный пакет :)))Смайлофаг вы мой дорогой, дело это не меняет. Сборка пакета в арче окружена chroot. Что же вы продолжаете тут троллить, вроде бы неглупый (или я ошибаюсь?)
>>Только если sandbox очень абстрактный пакет :)))
>
>Смайлофаг вы мой дорогой, дело это не меняет. Сборка пакета в арче
>окружена chroot. Что же вы продолжаете тут троллить, вроде бы неглупый
>(или я ошибаюсь?)а что тогда есть гентушные binpkgs? неабстрактные пакеты?
>а что тогда есть гентушные binpkgs? неабстрактные пакеты?Я честно говоря не знаю, а они тут вообще при чём?
>>а что тогда есть гентушные binpkgs? неабстрактные пакеты?
>
>Я честно говоря не знаю, а они тут вообще при чём?Это то же самое что вы имеете в арче.
Собираем из ебилда в пакет - ставим пакетным менеджером.
Всё-таки и они есть. Очень хорошо. Что-нибудь от этого изменилось?
А можно еще вопрос по арчу?Вы прямо весь софт установленный в вашей системе собираете PKGBUILD'ом в пакет предварительно, а потом ставили пакманом?
>Вы прямо весь софт установленный в вашей системе собираете PKGBUILD'ом в пакет
>предварительно, а потом ставили пакманом?Нет конечно, потому что в этом нет никакой необходимости. Есть необходимость или желание пересобрать пакет, выкинув (при условии того, что это в принципе возможно) некоторые зависимости/добавить свои по вкусу. Тем и хорош арч
>>Вы прямо весь софт установленный в вашей системе собираете PKGBUILD'ом в пакет
>>предварительно, а потом ставили пакманом?
>
>Нет конечно, потому что в этом нет никакой необходимости. Есть необходимость или
>желание пересобрать пакет, выкинув (при условии того, что это в
>принципе возможно) некоторые зависимости/добавить свои по вкусу. Тем и хорош арч
>Ну так в этом и главное отличие, я думаю, влияющее собственно на размер/понятность PKGBUILD/EBUILD.
У вас PKGBUILD собственно инструмент маинтайнера бинарного пакета и кубик-рубик для очень непоседливого пользователя, оно в принципе не предназначено для широкого повседневного использования.
И в арчевской схеме один существенный минус - автор (маинтайнер - я не знаю вашей инфраструктуры, извините) потенциально не заинтересован в собираемости PKGBUILD'а на максимально возможном числе конфигураций, в принципе по большей части ему достаточно чтобы сборка прошла именно у него. Что в принципе ведет к не решению проблем при сборке непонятных на вскидку, а к их обходу.
Честно, никогда не имел дела с арчем (просто факт), но то что делают при похожей инфраструктуре в стейбл дебиане маинтайнеры кое-каких пакетов, на мой взгляд, ужасно.P.S. Спасибо за интересную дискуссию. Узнал много нового для себя про Arch.
>У вас PKGBUILD собственно инструмент маинтайнера бинарного пакета и кубик-рубик для очень
>непоседливого пользователя, оно в принципе не предназначено для широкого повседневного использования.Безусловно, но стать непоседливым пользователе в нём ну очень просто
>
>И в арчевской схеме один существенный минус - автор (маинтайнер - я
>не знаю вашей инфраструктуры, извините) потенциально не заинтересован в собираемости PKGBUILD'а
>на максимально возможном числе конфигураций.Заинтересован конечно же, но да, если пользователь полез сам пересобирать пакеты, то ему необходимо быть готовым к возможным проблемам со сборкой (хотя уже тут можно напрямую репортить разрабу самой софтины, если есть проблемы со сборкой)
>в принципе по большей части ему достаточно чтобы сборка прошла именно у него. Что в принципе ведет
>к не решению проблем при сборке непонятных на вскидку, а к
>их обходу.С одной стороны да, а с другой, если напишешь багрепорт, будут всё равно будут разбираться
>Честно, никогда не имел дела с арчем (просто факт), но то что
>делают при похожей инфраструктуре в стейбл дебиане маинтайнеры кое-каких пакетов, на
>мой взгляд, ужасно.Да я бы сидел на дебиане долго, но к сожалению, безудержная тяга ко всему новому (и большему числу в версии софта) определили выбор, даже sid не спасал
>P.S. Спасибо за интересную дискуссию. Узнал много нового для себя про Arch.Вообщем-то не за что. И ещё, я не отрицаю преимуществ use флагов, но они же и корень усложнения самих ебилдов.
Кстати вот всем анонимам отличная возможность доказать преимущества PKGBUILD над EBUILD: http://archlinux.org.ru/forum/viewtopic.php?f=7&t=1326P.S. Раз PKBUILD настолько проще и понятнее, я думаю минут за 20 накидаете :)
Начинается, дикий баттхерт в голове, и попытки ужаленное самолюбие. Да, PKGBUILDа для офиса от инфры пока нет, но есть для go-openoffice - http://repos.archlinux.org/viewvc.cgi/go-openoffice/repos/ex... . Для сравнения покажите, что у вас творится в ебилде, можно будет посмеяться вместе.
>Начинается, дикий баттхерт в голове, и попытки ужаленное самолюбие. Да, PKGBUILDа для
>офиса от инфры пока нет, но есть для go-openoffice - http://repos.archlinux.org/viewvc.cgi/go-openoffice/repos/ex...
>. Для сравнения покажите, что у вас творится в ебилде, можно
>будет посмеяться вместе.В каком именно? Если в go-oo ebuild'e то там +- то же самое.
В infra ужас по одной тривиальной причине, не имеющей отношения к ebuild'ам - инфра до сих пор не используют сборщик от go-oo c дистрозависимыми конфигами.P.S. Ну давайте смеятся вместе. Начем я думаю с этого места --disable-kde\ :)
--enable-kde )) И соответствующую зависимость в depends . Жду ссылку на ебилд для go-oo, чтобы убедиться что там +/-
>--enable-kde )) И соответствующую зависимость в depends . Жду ссылку на ебилд
>для go-oo, чтобы убедиться что там +/-http://gentoo-portage.com/AJAX/Ebuild/32816/View
Можно пальцем мне показать, что там избыточного?
>Можно пальцем мне показать, что там избыточного?честно говоря уже начиная с pkg_setup() слабо понимаю, что там имелось ввиду
>>Можно пальцем мне показать, что там избыточного?
>
>честно говоря уже начиная с pkg_setup() слабо понимаю, что там имелось ввиду
>Как я уже писал выше, далее на 99% use флаги и максимально широкая собираемость.
>Начинается, дикий баттхерт в голове, и попытки ужаленное самолюбие. Да, PKGBUILDа для
>офиса от инфры пока нет, но есть для go-openoffice - http://repos.archlinux.org/viewvc.cgi/go-openoffice/repos/ex...
>. Для сравнения покажите, что у вас творится в ебилде, можно
>будет посмеяться вместе.это "md5sums=(...)" - жесть!
>На самом деле я думал лучше будет, а так, маловменяемая чехарда
> * http://repos.archlinux.org/viewvc.cgi/kdelibs/repos/extra-i6...
> * http://gentoo-portage.com/AJAX/Ebuild/88333/View
> * http://ecarux.de/ports/kdelibs/Pkgfile
>И для полного счастья посмотрите фряшные порты. Потом и поговорим, а возможно
>кто-то и закачаетсяМсье про dpkg-buildpackage не слыхал? Тогда о каких устрицах речь?
Я ламер - помогите понять - у пакета есть зависимости. Их составитель пакета сам вручную же и составляет, да? т.е. прописывает все программы и компоненты внешние которые нужны для пакета?
>Я ламер - помогите понять - у пакета есть зависимости. Их составитель
>пакета сам вручную же и составляет, да? т.е. прописывает все программы
>и компоненты внешние которые нужны для пакета?Вообщем-то да. Но тут надо понимать, что если пакету C требуется пакет B, который зависит от A, то достаточно в зависимость C поставить только B, и грамотная система сборки (будь то portage, abs с makepkg, и тд) всё сама разрешит и соберёт. Ну а конкретные зависимости легко узнаются из README, а что чаще от autotools или того, чем собирается софт (cmake и тд и тп). Написать скрипт, имея скелет дело плёвое.
>Представлен (http://giftwrap.tuxfamily.org/) первый релиз GiftWrap, GUI-интерфейс для упрощения создания пакетов для
>Ubuntu Linux, основанной на кодовой базе проекта Deb Creator (http://debcreator.cmsoft.net/). В
>настоящий момент поддерживается создание пакетов из набора исходных текстов с максимальной
>автоматизацией всех рутинных операций. В будущих версиях ожидается (http://giftwrap.wikia.com/wiki/Roadmap) возможность
>операций по модификации и обновлению содержимого пакетов, загрузке пакетов в PPA,
>разбиению пакета на части, автоформированию .desktop файлов и меню.
>
>URL: http://giftwrap.tuxfamily.org/
>Новость: http://www.opennet.me/opennews/art.shtml?num=21951Подитоживая, искренне надеюсь что в итоге со временем в arch получаться равноправные source/binary части.
Как впрочем и в gentoo ;)
Подитоживая отметим что приперлась толпа троллей которые по топику нихрена не сказали почти, зато про всякие посторонние ебилды и арчи понафлеймили.И куда смотрят модераторы?Или они только мои сообщения грохать умеют а пачка тролей и офтоперов с другими никами - это ничего, так и надо, дескать?
>куда смотрят модераторы? Или они только мои сообщения грохать умеют/me поперхнулся эклером
так ваши сообщения ещё и удаляют!? сколько же вы их пишете за день???
>/me поперхнулся эклеромТак держать, в правильном направлении идете, товарисчи :)
Что хотется вот сказать. Ваша толпа - это я 1 аноним и 1 регистрант, те нас всего 2е. И 2ое, хочется пособолезновать по поводу модераторского произвола, а то видит ли только у одного юсера294 их удаляют
>Что хотется вот сказать. Ваша толпа - это я 1 аноним и
>1 регистрант,Понимаете, определить количество анонимов в силу одинакового ника несколько проблематично.
>те нас всего 2е.
А офтопа про какие-то посторонние сущности развели как легион троллей.
>а то видит ли только у одного юсера294 их удаляют
Да нет, не только: порой еще прибивают без разбора целыми тредами все коменты вообще.В моем понимании если уж так хочется попрактиковаться в таком подходе - данный тред самое то что надо.Во всяком случае я как-то не очень понимаю каким боком всякие там бсд, генты и арчи а также порты, ебилды и прочая относятся к тулзам для создания пакетов убунты.
О! Как раз собирался создать страничку со своими сборками Wine не только с Mesa3D, но и с fglrx и nvidia-вариантами реализаций библиотеки OpenGL. Это даёт ощутимые плюсы, особенно для ATi. Но всё же главная фишка - в компиляции с DiB-патчами.
Ну, что ж... Потестил программу. Собрал последний SVN программы flashrom (перепрошивать BIOS - а та, что есть в репозитарии, не увидела мой чипсет) в Ubuntu 8.10 AMD64. Вот ссылка: http://rapidshare.com/files/239061312/flashrom_0.9.0-r555-1_... . Не судите строго - первая программа... Мог и нашаманить не то. Готовлюсь собрать Dosbox новый, pcsx2, pidgin, tkdvd, и wine. Итак, что же обнаружил.
Что строку configure и make никак не допишешь и недомодифицируешь... Я всего лишь хотел исправить prefix установки в /usr, а не в /usr/local. Пришлось править сам makefile. Программа сама добавила себя в меню "Программирование" - приятно... Когда я выбрал архив с исходным кодом, была ругань, что не нашлась директория с исходниками. Распаковал вручную и выбрал эту директорию, поставив галочку "Каталог с исходниками, не архив". Вписал зависимости, описание, а также зависимости для сборки. Версию умолчальную поменял на правильную, также предлагаемые зависимости стёр, не нужны. первый раз ничего не получилось, писало, что fakeroot не может удалить мне /usr/local/sbin/flashrom - нет прав. Тогда я перепробовал от суперпользователя - получилось. Но полученный deb-пакет оказался 3 килобайта и пустой. Попробовал от себя заново - получилось. Вот и исходники, вот и deb-пакет. Стоит сказать, что финальное окно имеет строчку с именем полученного архива, которую можно изменять. Но это ничего не делает. Это можно поправить... Когда я открыл посмотреть diff-файл, обнаружил забавную штуку. То, что я выбрал класс программы, архитектуру amd64, есть в этом файле, но указаны и параметры, которые были предложены по-умолчанию. Это архитектура any, ненужные зависимости...
Спасибо за программу! Он а- очень хорошая! Автор, лопиши её быстрее!
Вот ещё недочёты. Когда вводишь краткое описание программы (а его я просто копирую из пакета DosBOX из репозитария), то оно не влезает всё... А в полном описании в итоговом пакете Enter заменяется на пробел.
Спасибо, учтено.Но для будущего, пожалуйста, напишите репорт - https://bugs.launchpad.net/giftwrap/+filebug