[gentoo] Как правильно автоматически генерировать ebuild (или использовать шаблон?)? А не использовать ./configure && make && make install

делайте свои ебильды: http://devmanual.gentoo.org/

я разрешаю.

генерилка только для пакето, которые используют автотулзы, емнип
а вообще "./configure && make && make install "-ебилды пишутся элементарно

ktulhu666

Потому что их официальный манул меня весьма не впечатлил

ну можно семёрочку максимальную, ибо в других дистрах это либо ненамного проще(Slackware), либо значительно сложнее(всё остальное). А checkinstall это костыль, который работает через раз.

Пример ебилда (моего):
DESCRIPTION=«Microsoft Office 2010»
HOMEPAGE="http://office.microsoft.com"
SRC_URI=«mirror://download.microsoft.com/office/${P}.tar.gz»

LICENSE=«MS EULA»
SLOT=«0»
KEYWORDS=«~mips ~sparc ~x86»
IUSE=«»

#Рантайм-зависимости
RDEPEND=«dev-libs/win32-libs»
#Зависимости для компиляции
DEPEND=«${RDEPEND}
sys-devel/win32-dev
sys-devel/win32-api
sys-kernel/win32-kernel-sources»

src_configure() {
cd $S
rm -rf ./ms-spyware-2010
#выше написана комманда, которая мне нужна перед configure, которая должна исполнится в дирректории, куда был распакован архив
#нужен ли cd $S для перехода в SOURCES DIR?
./configure --with-posix-regex --without-bugs --without-viruses-suspoport --without-buffer-overflow --without-error-pack-2 --without-spyware --without-malware --enable-ultimate --with-pr0n || die
#или тут ОБЯЗАТЕЛЬНО econf юзать?
cat «EDEW-EERW-234D-DEFE-EFE3-DE33» > ./key
#выше написана комманда, которая мне нужна ПОСЛЕ configure, которая должна исполнится в дирректории, куда был распакован архив
}

src_compile() {
econf --with-posix-regex ||
emake || die
}

src_install() {
emake DESTDIR=«${D}» install || die
}

Его надо назвать app-office(каталог)/ms-office-2010.ebuild в каталоге моего локального оверлея, после чего сгенерировать манифест и всё? Какие ошибки я допустил в ебилде?

cd $S

не нужно

или тут ОБЯЗАТЕЛЬНО econf юзать?

да
и зачем configure 2 раза?

стоп
это что за херь? о_О

Аааа... Я забыл сказать. У меня Win9. В нём MS решит проблемы контроля версий общих библиотек, установки ПО, реестра и переносимости профилей пользователя.

cd $S

не нужно

Оно уже в этом каталоге, что ли, будет?

или тут ОБЯЗАТЕЛЬНО econf юзать?

да
и зачем configure 2 раза?

А, в src_compile() econf лишний. А почему надо econf то юзать? В /usr/portage/skel.ebuild написано, что я могу и ./configure юзать. Мне ./configure больше нравится.

И да - то, что я версию не указал, а только слот - это норм?

У меня девяточка ультимейт девелопер едишн без сервиспаков. Что мне делать?

Мне ./configure больше нравится.

это кастрат на фоне econf

Оно уже в этом каталоге, что ли, будет?

да

хватит пороть чушь
а уж сорсы офиса - это вообще феерия

освоить тег CODE.

megabaks, а econf это такая обёртка над ./configure? Я там ещё emake распарсил... Вообще - интересная система. Потом поставлю. Для опытов.

Мне ./configure больше нравится.

это кастрат на фоне econf

Но технически то я могу юзать ./configure, а не econf? Особых проблем не будет?

это такая обёртка над ./configure?

да

не будет
только это вульгарно и нет гибкости ака юзы

configure \
$(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)

Как так!?

не будет
только это вульгарно и нет гибкости ака юзы

Ты уверен, что не будет? emake разве не запустит econf, если он не был явно запущен ранее? Или каждая явная src_XXX() процедура говорит последующей о том, что всё удачно выполнено и её делать не надо?

Я не совсем понял про пропуски процедур. Насколько я понял, можно ебилд вообще без процедур написать, а ещё src_unpack() почти всегда пропускается.

зависит от используемых еклассов и собственно сорсов

какая порнография...

освоить тег CODE.

Что за тег? Кстати, вот Вы - слакварщик, а , вроде, не тупой... Странно всё это...

Можно более подробный ответ? Особенно касаемо пропусков процедур.

grep -RH -e "DESTDIR" /usr/portage/eclass/ | grep install

смотри соответствующие еклассы

да я чаем подавился, когда увидел

Вы сначала копирование на другой раздел с сохранением даты, posix rights, acl, xattrs и просмотр/смену uuid'а раздела (или смену его на новый в fstab) освойте. А потом будете в гентушные треды врываться.

Я правильно понимаю, что указав нужный eclass в соответствующей переменной в ебилде будет произведена подмена дефолтных (указанных в base.eclass) процедур на процедуры соответствующего екласса? А в случае написания какой-либо процедуры вручную в ебилде ею будет полностью замещена соответствующая процедура екласса для данного ебилда?

Также, согласно base.eclass, src_configure является обёрткой econf :
base_src_configure() {
debug-print-function $FUNCNAME «$@»

# there is no pushd ${S} so we can override its place where to run
[[ -x ${ECONF_SOURCE:-.}/configure ]] && econf «$@»
}

Но где можно посмотреть сам код econf?
И правильно ли я понял, что если я укажу, скажем, пустую процедуру src_unpack() {} в моём ебилде, то процесс пойдёт дальше (до src_configure), но завершится там (понятно дело) с ошибкой? Или econf всё-таки запустит дефолтную src_unpack?

Мне тоже непонятны эти ебилды. В дебиане, например, есть удобнейшая cdbs.

ktulhu666

Что за тег?

www.linux.org.ru/wiki/en/Lorcode

ktulhu666

вот Вы - слакварщик, а , вроде, не тупой... Странно всё это...

это как следует понимать? в слаке какие-то специальные секретные команды ассемблера применяются, что-бы мосг взрывать?
шапочка из фольги - наше всё!

anonymous

В дебиане, например, есть удобнейшая cdbs.

в дебе есть Over9000 костылей для сборки пакетов, и ни один из них нормально не работает.

Я правильно понимаю, что указав нужный eclass в соответствующей переменной в ебилде будет произведена подмена дефолтных (указанных в base.eclass) процедур на процедуры соответствующего екласса? А в случае написания какой-либо процедуры вручную в ебилде ею будет полностью замещена соответствующая процедура екласса для данного ебилда?

да

И правильно ли я понял, что если я укажу, скажем, пустую процедуру src_unpack() {} в моём ебилде, то процесс пойдёт дальше (до src_configure), но завершится там (понятно дело) с ошибкой?

да
но до этого ещё словишь хером по лбу, т.к. пустая функция не прокатит

Но где можно посмотреть сам код econf?

econf() {
	local x

	[[ " ${FEATURES} " == *" force-prefix "* ]] || \
		case "$EAPI" in 0|1|2) local EPREFIX= ;; esac

	_hasg() {
		local x s=$1
		shift
		for x ; do [[ ${x} == ${s} ]] && echo "${x}" && return 0 ; done
		return 1
	}

	_hasgq() { _hasg "$@" >/dev/null ; }

	local phase_func=$(_ebuild_arg_to_phase "$EAPI" "$EBUILD_PHASE")
	if [[ -n $phase_func ]] ; then
		if has "$EAPI" 0 1 ; then
			[[ $phase_func != src_compile ]] && \
				eqawarn "QA Notice: econf called in" \
					"$phase_func instead of src_compile"
		else
			[[ $phase_func != src_configure ]] && \
				eqawarn "QA Notice: econf called in" \
					"$phase_func instead of src_configure"
		fi
	fi

	: ${ECONF_SOURCE:=.}
	if [ -x "${ECONF_SOURCE}/configure" ]; then
		if [[ -n $CONFIG_SHELL && \
			"$(head -n1 "$ECONF_SOURCE/configure")" =~ ^'#!'[[:space:]]*/bin/sh([[:space:]]|$) ]] ; then
			sed -e "1s:^#![[:space:]]*/bin/sh:#!$CONFIG_SHELL:" -i "$ECONF_SOURCE/configure" || \
				die "Substition of shebang in '$ECONF_SOURCE/configure' failed"
		fi
		if [ -e "${EPREFIX}"/usr/share/gnuconfig/ ]; then
			find "${WORKDIR}" -type f '(' \
			-name config.guess -o -name config.sub ')' -print0 | \
			while read -r -d $'\0' x ; do
				vecho " * econf: updating ${x/${WORKDIR}\/} with ${EPREFIX}/usr/share/gnuconfig/${x##*/}"
				cp -f "${EPREFIX}"/usr/share/gnuconfig/"${x##*/}" "${x}"
			done
		fi

		# EAPI=4 adds --disable-dependency-tracking to econf
		if ! has "$EAPI" 0 1 2 3 3_pre2 && \
			"${ECONF_SOURCE}/configure" --help 2>/dev/null | \
			grep -q disable-dependency-tracking ; then
			set -- --disable-dependency-tracking "$@"
		fi

		# if the profile defines a location to install libs to aside from default, pass it on.
		# if the ebuild passes in --libdir, they're responsible for the conf_libdir fun.
		local CONF_LIBDIR LIBDIR_VAR="LIBDIR_${ABI}"
		if [[ -n ${ABI} && -n ${!LIBDIR_VAR} ]] ; then
			CONF_LIBDIR=${!LIBDIR_VAR}
		fi
		if [[ -n ${CONF_LIBDIR} ]] && ! _hasgq --libdir=\* "$@" ; then
			export CONF_PREFIX=$(_hasg --exec-prefix=\* "$@")
			[[ -z ${CONF_PREFIX} ]] && CONF_PREFIX=$(_hasg --prefix=\* "$@")
			: ${CONF_PREFIX:=${EPREFIX}/usr}
			CONF_PREFIX=${CONF_PREFIX#*=}
			[[ ${CONF_PREFIX} != /* ]] && CONF_PREFIX="/${CONF_PREFIX}"
			[[ ${CONF_LIBDIR} != /* ]] && CONF_LIBDIR="/${CONF_LIBDIR}"
			set -- --libdir="$(strip_duplicate_slashes ${CONF_PREFIX}${CONF_LIBDIR})" "$@"
		fi

		set -- \
			--prefix="${EPREFIX}"/usr \
			${CBUILD:+--build=${CBUILD}} \
			--host=${CHOST} \
			${CTARGET:+--target=${CTARGET}} \
			--mandir="${EPREFIX}"/usr/share/man \
			--infodir="${EPREFIX}"/usr/share/info \
			--datadir="${EPREFIX}"/usr/share \
			--sysconfdir="${EPREFIX}"/etc \
			--localstatedir="${EPREFIX}"/var/lib \
			"$@" \
			${EXTRA_ECONF}
		vecho "${ECONF_SOURCE}/configure" "$@"

		if ! "${ECONF_SOURCE}/configure" "$@" ; then

			if [ -s config.log ]; then
				echo
				echo "!!! Please attach the following file when seeking support:"
				echo "!!! ${PWD}/config.log"
			fi
			die "econf failed"
		fi
	elif [ -f "${ECONF_SOURCE}/configure" ]; then
		die "configure is not executable"
	else
		die "no configure script found"
	fi
}

Ваше фамилие, случаем, не Криворучко? [spoiler]УзнаЮ! УзнаЮ брата Колю![/spoiler]

не, в Ъ системах это делается значительно проще и без всяких костылей.

Освоил, врываюсь в тред. Кстати, новый диск очень хорошо работает

мм а где гибкость то ? В configure вообще ничего нет, кроме стандарта расположения, и возможность встраивания своего чего то не увидел Или такая возможность как то по другому реализуется ?
В слаке смотришь configure --help, где порой куча нужнейших опций

щас он тебе расскажет, что тебе нужно курить матчасть. а на прямой вопрос не ответит

это всё костыльное bloated уг. вот на арчике няшные pkgbuild-ы: обычный sh(баш) c небольшими наворотами™, без кучи говно-врапперов

да нет, у меня где то в половине прог в configure опции которых нет по умолчанию Если гента предлагает в configure жрать только то что дают по умолчанию нахер мне такая «гибкость»

да
но до этого ещё словишь хером по лбу, т.к. пустая функция не прокатит

Почему это не прокатит? Ну а если не пустая, а с реальным unpack'ом (допустим, я извлекаю из 7z или там архив в архиве)? И я, таки, не совсем понял, в чём ГЛАВНЫЕ отличия между версиями EAPI, кроме отсутствия возможности в первых версиях пропускать процедуры?

да нет, у меня где то в половине прог в configure опции которых нет по умолчанию Если гента предлагает в configure жрать только то что дают по умолчанию нахер мне такая «гибкость»

Читай манул. Ты можешь использовать ./configure вместе econf, если у тебя там реально что-то из ряда вот выходящее, однако (обычно) всё тоже самое можно указать после econf или в переменной EXTRA_ECONF. Плюс, можно через USE-флаги легко вводить в ебилд внешне переданные значения флагов. Но для этого надо использовать соответствующие опции, для одноразового (собственного) ебилда это не нужно обычно.

Сейчас глянул, у меня самые маленькие ebuild'ы такие:

net-im/risovaska/risovaska-1.5.0.ebuild

HOMEPAGE="http://risovaska.ru/"

FN="risovaska_1.5.0-0ubuntu_i386.deb"

SRC_URI="http://static.risovaska.ru/${FN}"

SLOT="0"
KEYWORDS="~x86"

src_unpack() {
    unpack ${FN}
    unpack ./data.tar.gz
}

src_install() {
    mv ${WORKDIR}/usr ${D}
}

app-accessibility/gnome-voice-control/gnome-voice-control-0.3.ebuild

DESCRIPTION="Gnome-Voice-Control is a speech recognizer to control the GNOME Desktop. It is developed on Google Summer of Code 2007."
HOMEPAGE="http://live.gnome.org/GnomeVoiceControl"
SRC_URI="http://download.berlios.de/festlang/${P}.tar.gz"

SLOT="0"
KEYWORDS="~x86"

DEPEND="
    >=gnome-extra/at-spi-1.0
    app-accessibility/sphinx2
"

app-misc/incollector/incollector-1.0.ebuild

inherit mono

DESCRIPTION="Incollector is an application to collect various kind of information."
HOMEPAGE="http://www.incollector.devnull.pl"
SRC_URI="http://www.incollector.devnull.pl/download/sources/${P}.tar.gz"
KEYWORDS="~amd64 ~x86"
SLOT="0"
LICENSE="GPL-2"
IUSE=""

RESTRICT="nomirror"

DEPEND=">=dev-dotnet/gtk-sharp-2.8
        >=dev-dotnet/glade-sharp-2.6
        dev-lang/mono"
RDEPEND="${DEPEND}"

src_install() {
    dodoc INSTALL COPYING README AUTHORS
    emake DESTDIR="${D}" install || die "emake install failed"
}

и т.д.

net-misc/4shared/4shared-1.3.1.ebuild

HOMEPAGE="http://4sync.com/features.jsp"

FN="desktop4shared-1.3_1-all.deb"

SRC_URI="http://dc415.4shared.com/download/x3JqSRo1/${FN}"

SLOT="0"
KEYWORDS="~x86"

RDEPEND="
    dev-java/slf4j-api
    dev-java/slf4j-nop
    dev-java/miglayout
    dev-java/wsdl4j
    dev-java/glazedlists
"

src_unpack() {
    unpack ${FN}
    unpack ./data.tar.gz
}

src_install() {
    mv ${WORKDIR}/usr ${D}
}

В net-im/risovaska/risovaska-1.5.0.ebuild что-нибудь (например, ./configure), кроме src_unpack и src_install, будет запущено?
Если нет, то почему, ведь (как говорил мегабакс) если процедура не указанна, то она будет автоматически исполнена из екласса при исполнении ебидла?
И почему нельзя сразу полный SRC_URI писать, а нужно FN=«risovaska_1.5.0-0ubuntu_i386.deb» указывать? FN, чтобы, используется при генерации манифеста и поиске в кэше скачанных файлов портажа?

И почему нельзя

1. Чтобы потом для новой версии смотреть только на имя файла.

2. Это всё «наколенные» ebuild'ы, лепленые на один раз за пару минут, потому и неоптимальные и странные, порой :)

См. вопросы выше, плюс такой вопрос: на какой стадии ебилд работает уже вне песочницы?
И как именно работа с ней происходит, чего стоит опасаться?
Можно ли как-нибудь настроить, чтобы при компиляции использовался не root, а ограниченный пользователь, чтобы не допустить побега из chroot'а?
Как именно манифест генерит для используемых файлов ебилда (и его самого) хэши? Точнее, откуда он берет эти файлы? Сам их выкачивает, как написанно в SRC_URI ебилда? Или надо что-то ручками делать?
Если у меня нету URI для скачки файла, то как мне указать использовать пакет из локальной ФС (грязный хак с подкладыванием файла в кэш файлов портажа не предлагать).

на какой стадии ебилд работает уже вне песочницы?

ebuild unpack/compile — сборка
ebuild install — установка результата в image (в том же /var/tmp/portage)
ebuild merge — добавление в систему

Между этими стадиями, кстати, можно даже вручную что-то поковырять, если операция всё равно одноразовая.

Точнее, откуда он берет эти файлы? Сам их выкачивает, как написанно в SRC_URI ебилда?

Да, выкачивает. При чём, если там файлы разных платформ, то все скачает, даже не нужные на данной.

Если у меня нету URI для скачки файла, то как мне указать использовать пакет из локальной ФС

Если файл уже лежит в distfiles, то оттуда возьмётся. Если файла и ссылки совсем нет — не пропишет на него дайджест.

кури дев-мануал

ebuild install работает в песочнице

During the src_unpack, src_compile, src_test and src_install phases, ebuild.sh operates inside a sandbox.

не просто так указывается дира назначения ака image

А можно компиляцию (и, возможно, другие шаги) выполнять от другого пользователя, чтобы избежать побега из chroot'а? Ведь root, он даже в песочнице рут, если не настроен SELinux.