# Помощь в создании ebuild-а

## malvikus

Помогите, пожалуйста, создать первый в жизни ebuild для https://source.tizen.org/documentation/reference/git-build-system/.

Что не так? Когда пытаюсь собрать, или хотя бы распаковать tar.gz получаю следующую ошибку:

ebuild   /usr/local/portage/dev-util/gbs/gbs-0.13_alpha.ebuild unpack

```

>>> Existing ${T}/environment for 'gbs-0.13_alpha' will be sourced. Run

>>> 'clean' to start with a fresh environment.

>>> Not marked as unpacked; recreating WORKDIR...

 * checking ebuild checksums ;-) ...                                                                                        [ ok ]

 * checking miscfile checksums ;-) ...                                                                                      [ ok ]

>>> Unpacking source...

>>> Unpacking gbs-0.13_alpha.tar.gz to /var/tmp/portage/dev-util/gbs-0.13_alpha/work

 * ERROR: dev-util/gbs-0.13_alpha failed (unpack phase):

 *   gbs-0.13_alpha.tar.gz does not exist

 * 

 * Call stack:

 *          ebuild.sh, line   93:  Called src_unpack

 *        environment, line 3719:  Called unpack 'gbs-0.13_alpha.tar.gz'

 *   phase-helpers.sh, line  297:  Called die

 * The specific snippet of code:

 *              [[ ! -s ${srcdir}${x} ]] && die "${x} does not exist"

 * 

 * If you need support, post the output of `emerge --info '=dev-util/gbs-0.13_alpha'`,

 * the complete build log and the output of `emerge -pqv '=dev-util/gbs-0.13_alpha'`.

 * This ebuild is from an overlay named 'x-portage': '/usr/local/portage/'

 * The complete build log is located at '/var/tmp/portage/dev-util/gbs-0.13_alpha/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/dev-util/gbs-0.13_alpha/temp/environment'.

 * Working directory: '/var/tmp/portage/dev-util/gbs-0.13_alpha/work'

 * S: '/var/tmp/portage/dev-util/gbs-0.13_alpha/work/gbs-0.13_alpha'

```

Вот сама заготовка ebuild-а:

```

# Copyright 1999-2013 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

EAPI=5

PYTHON_DEPEND="2:2.7:2.7"

inherit distutils

DESCRIPTION="Command line tool for building packages for Tizen platform"

HOMEPAGE="https://source.tizen.org/documentation/reference/git-build-system"

LICENSE="GPL-2"

SLOT="0"

IUSE=""

KEYWORDS="amd64 x86"

DEPEND="

   >=dev-util/osc-0.131

   dev-vcs/git

   app-arch/rpm

   dev-util/suse-build

"

RDEPEND="${DEPEND}

   app-admin/sudo

   dev-util/obs-service-meta

"

pkg_setup() {

   python_set_active_version 2

   python_pkg_setup

}

src_unpack() {

   unpack ${PF}.tar.gz

}

src_compile() {

   distutils_src_compile

}

src_install() {

   distutils_src_install

   ### Commented from original ebuild #

   #dosym osc-wrapper.py /usr/bin/osc

   #keepdir /usr/lib/osc/source_validators

   #cd "${ED}"/usr/

   #find . -type f -exec sed -i 's|/usr/bin/build|/usr/bin/suse-build|g'   {} +

   #find . -type f -exec sed -i 's|/usr/lib/build|/usr/share/suse-build|g' {} +

   #rm -f "${ED}"/usr/share/doc/${PN}*/TODO*

}

```

Здесь и лежит мой ebuild:

```

ls /usr/local/portage/dev-util/gbs/

Manifest  gbs-0.13.tar.gz  gbs-0.13_alpha.ebuild  gbs-0.13_alpha.tar.gz

cat /etc/portage/make.conf | grep DISTDIR

DISTDIR="/usr/local/portage/distfiles"

emerge -s "%@dev-util/gbs"

*  dev-util/gbs

      Latest version available: 0.13_alpha

      Latest version installed: [ Not Installed ]

      Size of files: 0 kB

      Homepage:      https://source.tizen.org/documentation/reference/git-build-system

      Description:   Command line tool for building packages for Tizen platform

      License:       GPL-2

```

----------

## Chocimier

Нужно додать 

```
SRC_URI="http://source.tizen.org/откуда/скачать/gbs-0.13_alpha.tar.gz"
```

----------

## Pinkbyte

1) Не указан источник исходных кодов(SRC_URI для tarball-ов или путь к cvs/svn/git-репозитарию для live ебилдов)

2) Использовать distutils eclass с новым EAPI не стоит - лучше смотреть в сторону distutils-r1

3) src_unpack можно удалить - она тут умолчальная. Остальные функции можно пока оставить как заготовки, потому что видно что ебилд еще сырой

Большего сказать не могу - надо предметно разбираться в том, на что пишется ебилд

----------

## malvikus

Большое спасибо за советы. Добавил SRC_URI, все заработало. Да, ebuild действительно очень сырой. По мере накопления знаний буду улучшать. Но у меня остался вопрос - gbs (git build system) невозможно скачать по прямой ссылке, её не существует. Для этого надо регистрироваться на сайте, создавать ssh ключ. Что указывать в таких случаях в SRC_URI, когда ссылки на исходный код не существует?

----------

## Pinkbyte

 *malvikus wrote:*   

> Большое спасибо за советы. Добавил SRC_URI, все заработало. Да, ebuild действительно очень сырой. По мере накопления знаний буду улучшать. Но у меня остался вопрос - gbs (git build system) невозможно скачать по прямой ссылке, её не существует. Для этого надо регистрироваться на сайте, создавать ssh ключ. Что указывать в таких случаях в SRC_URI, когда ссылки на исходный код не существует?

 

Это невозможно по лицензионным ограничениям? Тогда в SRC_URI указывается только имя скачиваемого файла и добавляется fetch restriction(строчка RESTRICT="fetch mirror")

Подробнее - http://devmanual.gentoo.org/ebuild-writing/variables/index.html :

 *Quote:*   

> RESTRICT 	A space-delimited list of portage features to restrict. Valid values are fetch, mirror, strip, test and userpriv. See man 5 ebuild for details. 

 

man 5 ebuild, интересующая нас секция:

```
       RESTRICT = [strip,mirror,fetch,userpriv]

              This should be a space delimited list of portage features to restrict.  You may use conditional syntax to vary restrictions as seen above in DEPEND.

              binchecks

                     Disable all QA checks for binaries.  This should ONLY be used in packages for which binary checks make no sense (linux-headers and kernel-sources,

                     for  example,  can safely be skipped since they have no binaries).  If the binary checks need to be skipped for other reasons (such as proprietary

                     binaries), see the QA CONTROL VARIABLES section for more specific exemptions.

              bindist

                     Distribution of built packages is restricted.

              fetch  like mirror but the files will not be fetched via SRC_URI either.

              installsources

                     Disables installsources for specific packages. This is for packages with binaries that are not compatible with debugedit.

              mirror files in SRC_URI will not be downloaded from the GENTOO_MIRRORS.

              primaryuri

                     fetch from URIs in SRC_URI before GENTOO_MIRRORS.

              strip  final binaries/libraries will not be stripped of debug symbols.

              test   do not run src_test even if user has FEATURES=test.

              userpriv

                     Disables userpriv for specific packages.
```

Ну и определить функцию pkg_nofetch, в которой рассказать откуда забирать данный файл вручную. За примером можно посмотреть ебилд на sun-jdk - там тоже ручное скачивание по причине лицензионной политики...

----------

## malvikus

Огромное спасибо, я бы очень долго искал эту информацию. Т.к. google ничего внятного для таких случаев не дал. 

Т.к. вы очень хорошо разбираетесь в теме, хотел бы спросить у вас совета. 

Те самые исходники GBS являются open-source и лицензируются, насколько я помню, под GPL-2. Однако прямой ссылки на скачивание без авторизации на них нет. Т.е. проблем скачать их нет, только сначала для этого зарегистрируйся на tizen.org, настрой ssh ключи. Я подумал и решил, что самым оптимальным в данном случае будет создание user overlay на gentoo.org. Куда я буду периодически класть обновленные tar.gz, а в ebuild в SRC_URI указывать ссылку на эти архивы. Что вы об этом думаете? Или есть лучший вариант?

----------

## Pinkbyte

 *malvikus wrote:*   

>  Я подумал и решил, что самым оптимальным в данном случае будет создание user overlay на gentoo.org. Куда я буду периодически класть обновленные tar.gz, а в ebuild в SRC_URI указывать ссылку на эти архивы. Что вы об этом думаете? Или есть лучший вариант?

 

Насколько мне известно, оверлей, выдаваемый на gentoo.org - это всего-лишь репозитарий для ебилдов(неважно, svn или git). Хотя туда и можно положить бинарный файл, делать это не рекомендуется - системы контроля версий без дополнительного вмешательства малопригодны для хранения бинарных файлов, тут лучше задуматься о каком-нибудь хостинге.

И, да, если у вас уже есть оверлей, для того чтобы он попал в layman он не обязан быть расположен на gentoo.org.

В любом случае данный вопрос(добавление существующего оверлея в список layman или создание нового на gentoo.org, с последующим добавлением) решаются одинаково - заводится баг на bugs.gentoo.org. Примеры - https://bugs.gentoo.org/show_bug.cgi?id=383255 (запрос на добавление существующего пользовательского оверлея в список layman), https://bugs.gentoo.org/show_bug.cgi?id=417281 (запрос на создание нового оверлея).

 *malvikus wrote:*   

> Те самые исходники GBS являются open-source и лицензируются, насколько я помню, под GPL-2.

 

http://download.tizen.org/tools/latest-release/Ubuntu_12.10/gbs_0.13-1.tar.gz

Это какие-то исходники, не уверен, что те, которые вам нужны, но они - в открытом доступе.

Хотя в README в этом архиве написано:

 *Quote:*   

> Gbs source code is managed by Gerrit in tizen staging zone(temporarily), you
> 
> need an account to access it.

 

Получается что закрыт только репозитарий, а тарболлы релизов публикуются, так? Или я чего-то не понимаю?

----------

