Quickstart Ebuild Guide 문서 번역

Quickstart Ebuild Guide.pdf

Quickstart Ebuild Guide 문서 번역

https://devmanual.gentoo.org/quickstart/index.html

Quickstart Ebuild Guide

This page provides a very brief introduction to ebuild writing. It does not attempt to cover many of the details or problems that will be encountered by developers — rather, it gives some trivial examples which may be of use when trying to grasp the basic idea of how ebuilds work.

이 페이지에서는 ebuild file을 쓰기 위한 매우 간략한 소개만 하고 있다. 개발자들이 읽을 때 만날 수 있는 문제나 자세한 설명을 하기보다 ebuild가 어떻게 작동하는 지에 대한 기본적인 내용을 알려주기 위해 간단한 예제를 보여준다.

For proper coverage of all the ins and outs, see Ebuild Writing. The General Concepts chapter will also be of use.

모든 내용을 보기 위해선 Ebuild Writing 페이지를 보라. General Concepts 챕터도 도움이 될 것이다.

Note that the examples used here, whilst based upon real tree ebuilds, have had several parts chopped out, changed and simplified.

여기에 의한 예제들은 실제 ebuild들의 내용에 기초하고 있으나, 여러 파트에서 짤라 내 와 변경하고 간략하게 만들었다.

First Ebuild

We'll start with an ebuild for the Exuberant Ctags utility, a source code indexing tool. Here's a simplified dev-util/ctags/ctags-5.5.4.ebuild (you can see real ebuilds in the main tree).

우리는 source code indexing tool인 Exuberant Ctags 유틸리티를 위한 ebuild로 시작할 것이다. 간략한 dev-util/ctags/ctags-5.5.4.ebuild 이다.

# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI=5

DESCRIPTION="Exuberant ctags generates tags files for quick source navigation"
HOMEPAGE="http://ctags.sourceforge.net"
SRC_URI="mirror://sourceforge/ctags/${P}.tar.gz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~mips ~sparc ~x86"

src_configure() {
    econf --with-posix-regex
}

src_install() {
    emake DESTDIR="${D}" install

dodoc FAQ NEWS README
    dohtml EXTENDING.html ctags.html
}

Basic Format

As you can see, ebuilds are just bash scripts that are executed within a special environment.

보다시피, ebuild는 특정한 환경 내에서 실행되는 그냥 bash 스크립트이다.

At the top of the ebuild is a header block. This is present in all ebuilds.

ebuild의 제일 위에는 header block이다. 모든 ebuild file에 있다.

Ebuilds are indented using tabs, with each tab representing four places. See Ebuild File Format.

ebuild는 tab을 사용하려 한다. tab은 space 4개이다. Ebuild File Format 참조.

Information Variables

Next, there are a series of variables. These tell Portage various things about the ebuild and package in question.

다음으로, 여러 변수들이 나온다. 이것들은 portage에게 ebuild 및 package의 다양한 것들을 설명한다.

The EAPI of the ebuild, see EAPI Usage and Description.

The DESCRIPTION variable is set to a short description of the package and its purpose.

The HOMEPAGE is a link to the package's homepage (remember to include the http:// part).

The SRC_URI tells Portage the address to use for downloading the source tarball. Here, mirror://sourceforge/ is a special notation meaning "any of the Sourceforge mirrors".${P} is a read-only variable set by Portage which is the package's name and version — in this case, it would be ctags-5.5.4.

The LICENSE is GPL-2 (the GNU General Public License version 2).

The SLOT variable tells Portage which slot this package installs to. If you've not seen slots before, either just use "0" or read Slotting.

The KEYWORDS variable is set to archs upon which this ebuild has been tested. We use ~ keywords for newly written ebuilds — packages are not committed straight to stable, even if they seem to work. See Keywording for details.

Build Functions

Next, a function named src_configure. Portage will call this function when it wants to configure the package. The econf function is a wrapper for calling ./configure. If for some reason an error occurs in econf, Portage will stop rather than trying to continue with the install.

다음으로 src_configure function이다. Portage는 package를 configure하려할 때 이 function을 부른다. econf 함수는 ./configure를 부르는 wrapper이다. econf에서 error가 발생하는 할 경우, Portage는 계속 installation을 진행하기 보다 멈출 것이다.

The src_install function is called by Portage when it wants to install the package. A slight subtlety here — rather than installing straight to the live filesystem, we must install to a special location which is given by the ${D} variable (Portage sets this — see Install Destinations and Sandbox).

src_install function은 Portage가 package를 install하려 할 때 불린다. 작은 차이는 file system에 직접 install하기 보단 ${D}변수에 의해 지정된 위치에 반드시 설치해야 한다.

Note: The canonical install method is emake DESTDIR="${D}" install. This will work with any properly written standard Makefile. If this gives sandbox errors, try einstallinstead. If this still fails, see src_install for how to do manual installs.

알아둘 것: 표준 install 방법은 emake DESTDIR="${D}" install이다. 이는 적절한 표준 Makefile 에서 동작할 것이다. 만약 sandbox 에러가 발생한다면, 대신에 einstall을 시도해라. 만약 이것도 실패하면, 수동으로 install하는 방법을 위해 src_install을 보라.

The dodoc and dohtml are helper functions for installing files into the relevant part of /usr/share/doc.

dodoc과 dohtml은 /usr/share/doc의 적절한 위치에 파일을 intall하기 위한 function이다.

Ebuilds can define other functions (see Ebuild Functions). In all cases, Portage provides a reasonable default implementation which quite often does the 'right thing'. There was no need to define src_unpack and src_compile functions here, for example — the src_unpack function is used to do any unpacking of tarballs or patching of source files, but the default implementation does everything we need in this case. Similarly, the default src_compile function will call emake which is a wrapper for make.

ebuild는 다른 function들도 작성할 수 있다(Ebuild Functions을 보라). 모든 경우에서, Portage는 꽤 자주 맞는 일을 하는 적절한 기본 구현을 제공한다. 여기서는 src_unpack 과 src_compile은 작성할 필요가 없었다. 예로 src_unpack function은 tarball을 unpacking하거나 source file을 patch 할 때 쓰이며, 이 경우 우리가 필요한 모든 것을 default 구현이 모든 것을 처리했다. 비슷하게 기본 src_compile function은 make wrapper인  emake를 호출할 것이다.

Note: Formerly, the || die construct had to be used after every command to check for errors. This is no longer necessary in EAPI 4 — functions provided by Portage will die by themselves if something failed.

알아둘 것: 이전에 모든 명령에 대한 error에 점검 후에 || die 가 사용되어야 했다. 이는 EAPI 4에서는 더 이상 필요하지 않다. Portage가 제공하는 function은 문제가 생길 경우 스스로 죽는다.

Ebuild with Dependencies

In the ctags example, we didn't tell Portage about any dependencies. As it happens, that's ok, because ctags only needs a basic toolchain to compile and run (see Implicit System Dependency for why we don't need to depend upon those explicitly). However, life is rarely that simple.

ctags 예제에서, Portage의 여러 dependency에 대해 언급하지 않았다. ctags는 compile과 실행할 때 기본적인 toolchain만 필요했으므로 그게 가능하다(명시적으로 왜 그것들에 대해 필요가 없는지  Implicit System Dependency 를 보라). 그러나 실제는 그렇게 간단하지 않다.

Here's app-misc/detox/detox-1.1.1.ebuild:

여기에 app-misc/detox/detox-1.1.1.ebuild 가 있다:

# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI=5

DESCRIPTION="detox safely removes spaces and strange characters from filenames"
HOMEPAGE="http://detox.sourceforge.net/"
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.bz2"

LICENSE="BSD"
SLOT="0"
KEYWORDS="~hppa ~mips sparc x86"

RDEPEND="dev-libs/popt"
DEPEND="${RDEPEND}
    sys-devel/flex
    sys-devel/bison"

src_configure() {
    econf --with-popt
}

src_install() {
    emake DESTDIR="${D}" install
    dodoc README CHANGES
}

Again, you can see the ebuild header and the various informational variables. In SRC_URI, ${PN} is used to get the package's name without the version suffix (there are more of these variables — see Predefined Read-Only Variables).

다시, ebuild header와 여러 정보성 변수들을 볼 수 있다. SRC_URI 에서 ${PN}는 version suffix없이 package의 이름을 알기 위해 사용됐다(여기 더 많은 변수들이 있다 - Predefined Read-Only Variables를 보라).

Again, we define src_configure and src_install functions.

다시, 우린 src_configure 와 src_install function을 define한다.

The DEPEND and RDEPEND variables are how Portage determines which packages are needed to build and run the package. The DEPEND variable lists compile-time dependencies, and the RDEPEND lists runtime dependencies. See Dependencies for some more complex examples.

DEPEND 와 RDEPEND 변수들은 Portage가 어떤 package들이 이 package를 build하고 실행하는데 필요한 지 결정하는 방법이다.  DEPEND 변수는 compile time에 대한 dependency들을 list하며, RDEPEND 는 runtime dependency를 list한다. 다른 좀 더 복잡한 예제는 Dependencies 를 보라.

Ebuild with Patches

Often we need to apply patches. This is done in the src_prepare function using the epatch helper function. To use epatch one must first tell Portage that the eutils eclass (an eclass is like a library) is required — this is done via inherit eutils at the top of the ebuild. Here's app-misc/detox/detox-1.1.0.ebuild:

종종 우리는 patch를 적용해야 한다. 이는 epatch helper function을 사용하는 src_prepare function에서 이루어 진다.  epatch 를 사용하기는 Portage에게 eutils eclass(eclass는 library와 비슷하다)가 필요하다는 것을 알려줘야 한다. 이는 ebuild의 상단에 있는 inherit eutils을 통해 이루어 진다. 여기 app-misc/detox/detox-1.1.0.ebuild 가 있다:

# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI=5

inherit eutils

DESCRIPTION="detox safely removes spaces and strange characters from filenames"
HOMEPAGE="http://detox.sourceforge.net/"
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.bz2"

LICENSE="BSD"
SLOT="0"
KEYWORDS="~hppa ~mips ~sparc ~x86"

RDEPEND="dev-libs/popt"
DEPEND="${RDEPEND}
    sys-devel/flex
    sys-devel/bison"

src_prepare() {
    epatch "${FILESDIR}"/${P}-destdir.patch \
        "${FILESDIR}"/${P}-parallel_build.patch
}

src_configure() {
    econf --with-popt
}

src_install() {
    emake DESTDIR="${D}" install
    dodoc README CHANGES
}

Note the ${FILESDIR}/${P}-destdir.patch — this refers to detox-1.1.0-destdir.patch, which lives in the files/ subdirectory in the Portage tree. Larger patch files must go on your developer's space at dev.gentoo.org rather than in files/ or mirrors — see Gentoo Mirrors and Patching with epatch.

이 ${FILESDIR}/${P}-destdir.patch는 detox-1.1.0-destdir.patch 를 참조하는 것을 알아두라. 이것은 Portage tree의 files/ subdirectory에 있다. 더 큰 patch file은 files/ 이나 mirror보다 dev.gentoo.org 에 있는 당신의 개발자 공간에 두어야 한다.  Gentoo Mirrors 와 Patching with epatch를 보라.

Ebuild with USE Flags

Now for some USE flags. Here's dev-libs/libiconv/libiconv-1.9.2.ebuild, a replacement iconv for libc implementations which don't have their own.

이제 USE flag 차례이다. 여기 libc가 가지고 있지 않는 libc구현을 위한 대체 iconv인 dev-libs/libiconv/libiconv-1.9.2.ebuild가 있다.

# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI=5

DESCRIPTION="GNU charset conversion library for libc which doesn't implement it"
HOMEPAGE="http://www.gnu.org/software/libiconv/"
SRC_URI="ftp://ftp.gnu.org/pub/gnu/libiconv/${P}.tar.gz"

LICENSE="LGPL-2.1"
SLOT="0"
KEYWORDS="~amd64 ~ppc ~sparc ~x86"
IUSE="nls"

DEPEND="!sys-libs/glibc"

src_configure() {
    econf $(use_enable nls)
}

src_install() {
    emake DESTDIR="${D}" install
}

Note the IUSE variable. This lists all (non-special) use flags that are used by the ebuild. This is used for the emerge -pv output, amongst other things.

IUSE 변수에 대해 알아두라. 이는 ebuild가 사용하는 모든(특별하지 않은) use flag들을 나타낸다. 이는 다른 것들 사이에 있는 emerge -pv 출력 결과에서 사용된다.

The package's ./configure script takes the usual --enable-nls or --disable-nls argument. We use the use_enable utility function to generate this automatically, depending on the user's USE flags (see Query Functions Reference).

package ./configure script는 보통의 --enable-nls 또는 --disable-nls argument를 사용한다. 우리는 user의 USE flag들에 따라 argument를 자동으로 생성하는 use_enable utility function을 사용한다(Query Functions Reference 를 보라).

Another more complicated example, this time based upon mail-client/sylpheed/sylpheed-1.0.4.ebuild:

이번엔 다른 더 복잡한 예제로 mail-client/sylpheed/sylpheed-1.0.4.ebuild 를 보자:

# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI=5

inherit eutils

DESCRIPTION="A lightweight email client and newsreader"
HOMEPAGE="http://sylpheed.good-day.net/"
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.bz2"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="alpha amd64 hppa ia64 ppc ppc64 sparc x86"
IUSE="crypt imlib ipv6 ldap nls pda ssl xface"

RDEPEND="=x11-libs/gtk+-2*
    crypt? ( >=app-crypt/gpgme-0.4.5 )
    imlib? ( media-libs/imlib2 )
    ldap? ( >=net-nds/openldap-2.0.11 )
    pda? ( app-pda/jpilot )
    ssl? ( dev-libs/openssl )
    xface? ( >=media-libs/compface-1.4 )
    app-misc/mime-types
    x11-misc/shared-mime-info"
DEPEND="${RDEPEND}
    dev-util/pkgconfig
    nls? ( >=sys-devel/gettext-0.12.1 )"

src_prepare() {
    epatch "${FILESDIR}"/${PN}-namespace.diff \
        "${FILESDIR}"/${PN}-procmime.diff
}

src_configure() {
    econf \
        $(use_enable nls) \
        $(use_enable ssl) \
        $(use_enable crypt gpgme) \
        $(use_enable pda jpilot) \
        $(use_enable ldap) \
        $(use_enable ipv6) \
        $(use_enable imlib) \
        $(use_enable xface compface)
}

src_install() {
    emake DESTDIR="${D}" install

doicon sylpheed.png
    domenu sylpheed.desktop

dodoc [A-Z][A-Z]* ChangeLog*
}

Note the optional dependencies. Some of the use_enable lines use the two-argument version — this is helpful when the USE flag name does not exactly match the ./configureargument.

optional dependency들을 알아두라. 일부 use_enable 들은 two-argument 형을 사용한다. 이는 USE flag들이  ./configure argument와 정확히 일치하지 않을 때 도움이 된다.

 

출처: <https://devmanual.gentoo.org/quickstart/index.html>