[gentoo-dev] bzr.eclass into Portage

[gentoo-dev] bzr.eclass into Portage

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

Hi,

in the Emacs overlay we imported the bzr.eclass from the xeffects
overlay.  In the near future Emacs development will switch from CVS to
Bazaar and thus we need the new eclass in Portage to still provide our
live ebuilds from app-editors/emacs-cvs.  Question is now, who wrote
it?

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] bzr.eclass into Portage

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

Christian Faulhammer kirjoitti:
> Hi,
> 
> in the Emacs overlay we imported the bzr.eclass from the xeffects
> overlay.  In the near future Emacs development will switch from CVS to
> Bazaar and thus we need the new eclass in Portage to still provide our
> live ebuilds from app-editors/emacs-cvs.  Question is now, who wrote
> it?
> 
> V-Li
> 

Look at the SCM history in xeffects?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] bzr.eclass into Portage

[Jorge Manuel B. S. Vicetto]

Petteri Räty wrote:
> Christian Faulhammer kirjoitti:
>> Hi,
>>
>> in the Emacs overlay we imported the bzr.eclass from the xeffects
>> overlay.  In the near future Emacs development will switch from CVS to
>> Bazaar and thus we need the new eclass in Portage to still provide our
>> live ebuilds from app-editors/emacs-cvs.  Question is now, who wrote
>> it?
>>
>> V-Li
>>
> 
> Look at the SCM history in xeffects?
> 
> Regards,
> Petteri
> 


Better yet, look at the desktop-effects overlay[1] and check the history 
of the eclass[2].

  [1] - 
http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=summary
  [2] - 
http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=history;f=eclass/bzr.eclass;h=a2154a15114b8321d2f146fd3c0a578d6e28ddfe;hb=HEAD

-- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / SPARC
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: bzr.eclass into Portage

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>:

> Petteri Räty wrote:
> > Christian Faulhammer kirjoitti:
> >> in the Emacs overlay we imported the bzr.eclass from the xeffects
> >> overlay.  In the near future Emacs development will switch from
> >> CVS to Bazaar and thus we need the new eclass in Portage to still
> >> provide our live ebuilds from app-editors/emacs-cvs.  Question is
> >> now, who wrote it?
> >
> > Look at the SCM history in xeffects?
>
> Better yet, look at the desktop-effects overlay[1] and check the
> history of the eclass[2].

 I could not find the xeffects overlay...ok, Jorge you seem to be the
author.  So is it ready to import to Portage?

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: bzr.eclass into Portage

[Jorge Manuel B. S. Vicetto]

Christian Faulhammer wrote:
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>:
> 
>> Petteri Räty wrote:
>>> Christian Faulhammer kirjoitti:
>>>> in the Emacs overlay we imported the bzr.eclass from the xeffects
>>>> overlay.  In the near future Emacs development will switch from
>>>> CVS to Bazaar and thus we need the new eclass in Portage to still
>>>> provide our live ebuilds from app-editors/emacs-cvs.  Question is
>>>> now, who wrote it?
>>> Look at the SCM history in xeffects?
>> Better yet, look at the desktop-effects overlay[1] and check the
>> history of the eclass[2].
> 
>  I could not find the xeffects overlay...ok, Jorge you seem to be the
> author.  So is it ready to import to Portage?
> 
> V-Li
> 

Christian,

you can check the current version used in desktop-effects at 
http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=master
With the help of Ingmar we did some cleanup and added support for 
eclass-manpages at 
http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr. 
I'll be moving the updated eclass to the master branch, testing and 
asking users to try it out during this weekend.
This eclass is used in the overlay for the live avant-window-navigator 
ebuilds, so it's probably not as used/tested as the remaining packages. 
It has provided us the support we needed for awn, but you might need 
additional features or to review existing ones.
Please test the updated eclass on your overlay, feel free to maintain it 
and, when you think its ready, add it to the tree. When you do so, I'll 
remove it from our overlay and we'll use the eclass on the tree.

PS - You can get the last snapshot from the xeffects tree from my 
overlay - 
http://git.overlays.gentoo.org/gitweb/?p=dev/jmbsvicetto.git;a=summary

-- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / SPARC / KDE
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: bzr.eclass into Portage

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Hi,

"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>:
> you can check the current version used in desktop-effects at 
> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=master

 Yes, I did not find xeffects, but desktop-effects I now know.

> With the help of Ingmar we did some cleanup and added support for 
> eclass-manpages at 
> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr. 
> I'll be moving the updated eclass to the master branch, testing and 
> asking users to try it out during this weekend.
> This eclass is used in the overlay for the live
> avant-window-navigator ebuilds, so it's probably not as used/tested
> as the remaining packages. It has provided us the support we needed
> for awn, but you might need additional features or to review existing
> ones. Please test the updated eclass on your overlay, feel free to
> maintain it and, when you think its ready, add it to the tree. When
> you do so, I'll remove it from our overlay and we'll use the eclass
> on the tree.

 We have a prior version for some time now in the Emacs overlay for two
live ebuilds...so we go and merge your changed (ulm already did), test
it and report any problems.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: bzr.eclass into Portage

[René 'Necoro' Neumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Christian Faulhammer schrieb:
|  We have a prior version for some time now in the Emacs overlay for two
| live ebuilds...so we go and merge your changed (ulm already did), test
| it and report any problems.

I just copied the bzr.eclass from the desctop-effects overlay over to my
own one. And I had to find out, that bzr fails when updating an ebuild
which uses the "lp:" address scheme[1]. So perhaps, the support for this
scheme should be removed until it is fixed.

Regards,
Necoro

[1] https://bugs.launchpad.net/bzr/+bug/181945
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6FVC4UOg/zhYFuARAkmbAJ0cFEFGeZubvjhocmgPcTFXL6hdzACfYpGE
WP5z9YJri1NZzdQkHQ/Nv7E=
=YWvP
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: bzr.eclass into Portage

[René 'Necoro' Neumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

René 'Necoro' Neumann schrieb:
| Hi,
|
| Christian Faulhammer schrieb:
| |  We have a prior version for some time now in the Emacs overlay for two
| | live ebuilds...so we go and merge your changed (ulm already did), test
| | it and report any problems.
|
| I just copied the bzr.eclass from the desctop-effects overlay over to my
| own one. And I had to find out, that bzr fails when updating an ebuild
| which uses the "lp:" address scheme[1]. So perhaps, the support for this
| scheme should be removed until it is fixed.
|
| Regards,
| Necoro
|
| [1] https://bugs.launchpad.net/bzr/+bug/181945

Ok - seems like it got fixed in the meantime ... (bug is open for
several months --- and then gets fixed minutes after I post here ... ;))

I guess this fix will make it into bzr-1.4. Should the eclass then
depend on this version or should it still not allow the lp:-scheme?

Regards,
Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6Rfv4UOg/zhYFuARAsgFAJoDn9csUloGQxZ4tHhInKxQ2LvkTwCeJRg0
xNqxCP0FbbgG22At64IcovU=
=G5Er
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: bzr.eclass into Portage

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

Hi,

René 'Necoro' Neumann <lists@necoro.eu>:
> I guess this fix will make it into bzr-1.4. Should the eclass then
> depend on this version or should it still not allow the lp:-scheme?

 This eclass is still experimental...but I am all for raising the
version requirement and allow as much features as possible.  Let's wait
for 1.4 then.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: bzr.eclass into Portage

[Ulrich Mueller]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1383 bytes --]

>>>>> On Fri, 21 Mar 2008, Christian Faulhammer wrote:

> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>:
>> With the help of Ingmar we did some cleanup and added support for 
>> eclass-manpages at 
>> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr. 
>> I'll be moving the updated eclass to the master branch, testing and 
>> asking users to try it out during this weekend.
>> This eclass is used in the overlay for the live
>> avant-window-navigator ebuilds, so it's probably not as used/tested
>> as the remaining packages. It has provided us the support we needed
>> for awn, but you might need additional features or to review existing
>> ones. Please test the updated eclass on your overlay, feel free to
>> maintain it and, when you think its ready, add it to the tree. When
>> you do so, I'll remove it from our overlay and we'll use the eclass
>> on the tree.

>  We have a prior version for some time now in the Emacs overlay for
> two live ebuilds...so we go and merge your changed (ulm already
> did), test it and report any problems.

As I just learned there are (at least) three overlays using
bzr.eclass, namely desktop-effects, emacs, and ltsp.

So I think it is justified to move bzr.eclass to the Portage tree.
Currect version of bzr.eclass is attached.

Please raise your objections *now*.

Ulrich


[-- Attachment #2: bzr.eclass --]
[-- Type: text/plain, Size: 6494 bytes --]

# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# @ECLASS: bzr.eclass
# @MAINTAINER:
# Jorge Manuel B. S. Vicetto <jmbsvicetto>@gentoo.org
# @BLURB: This eclass provides support to use the Bazaar DSCM
# @DESCRIPTION:
# The bzr.eclass provides support for apps using the bazaar DSCM (distributed source control management system).
# The eclass was originally derived from the git eclass.
#
# Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
# this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.

inherit eutils

EBZR="bzr.eclass"

EXPORT_FUNCTIONS src_unpack

HOMEPAGE="http://bazaar-vcs.org/"
DESCRIPTION="Based on the ${EBZR} eclass"

DEPEND=">=dev-util/bzr-0.92"

# @ECLASS-VARIABLE: EBZR_STORE_DIR
# @DESCRIPTION:
# The dir to store the bzr sources.
EBZR_STORE_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src"

# @ECLASS-VARIABLE: EBZR_FETCH_CMD
# @DESCRIPTION:
# The bzr command to fetch the sources.
EBZR_FETCH_CMD="bzr branch"

# @ECLASS-VARIABLE: EBZR_UPDATE_CMD
# @DESCRIPTION:
# The bzr command to update the sources.
EBZR_UPDATE_CMD="bzr pull"

# @ECLASS-VARIABLE: EBZR_DIFFSTAT_CMD
# @DESCRIPTION:
# The bzr command to get the diffstat output.
EBZR_DIFFSTAT_CMD="bzr diff"

# @ECLASS-VARIABLE: EBZR_EXPORT_CMD
# @DESCRIPTION:
# The bzr command to export a branch.
EBZR_EXPORT_CMD="bzr export"

# @ECLASS-VARIABLE: EBZR_REVNO_CMD
# @DESCRIPTION:
# The bzr command to list revision number of the branch.
EBZR_REVNO_CMD="bzr revno"

# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
# The options passed to the fetch and update commands.
EBZR_OPTIONS="${EBZR_OPTIONS:-}"

# @ECLASS-VARIABLE: EBZR_REPO_URI
# @DESCRIPTION:
# The repository uri for the source package.
#
# @CODE
# Supported protocols:
# 		- http://
# 		- https://
# 		- sftp://
# 		- rsync://
# 		- lp://
# @CODE
#
# Note: lp = https://launchpad.net
EBZR_REPO_URI="${EBZR_REPO_URI:-}"

# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
# @DESCRIPTION:
# Bootstrap script or command like autogen.sh or etc.
EBZR_BOOTSTRAP="${EBZR_BOOTSTRAP:-}"

# @ECLASS-VARIABLE: EBZR_PATCHES
# @DESCRIPTION:
# bzr eclass can apply patches in bzr_bootstrap().
# you can use regexp in this valiable like *.diff or *.patch or etc.
# NOTE: this patches will applied before EBZR_BOOTSTRAP is processed.
#
# Patches are searched both in ${PWD} and ${FILESDIR}, if not found in either
# location, the installation dies.
EBZR_PATCHES="${EBZR_PATCHES:-}"

# @ECLASS-VARIABLE: EBZR_BRANCH
# @DESCRIPTION:
# The branch to fetch in bzr_fetch().
#
# default: trunk
EBZR_BRANCH="${EBZR_BRANCH:-trunk}"

# @ECLASS-VARIABLE: EBZR_REVISION
# @DESCRIPTION:
# Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
EBZR_REVISION="${EBZR_REVISION:-}"

# @ECLASS-VARIABLE: EBZR_CACHE_DIR
# @DESCRIPTION:
# The dir to store the source for the package, relative to EBZR_STORE_DIR.
#
# default: ${PN}
EBZR_CACHE_DIR="${EBZR_CACHE_DIR:-${PN}}"

# @FUNCTION: bzr_fetch
# @DESCRIPTION:
# Wrapper function to fetch sources from bazaar via bzr fetch or bzr update,
# depending on whether there is an existing working copy in ${EBZR_BRANCH_DIR}.
bzr_fetch() {
	local EBZR_BRANCH_DIR

	# EBZR_REPO_URI is empty.
	[[ -z ${EBZR_REPO_URI} ]] && die "${EBZR}: EBZR_REPO_URI is empty."

	# check for the protocol or pull from a local repo.
	if [[ -z ${EBZR_REPO_URI%%:*} ]] ; then
		case ${EBZR_REPO_URI%%:*} in
			# lp:// is https://launchpad.net
			http|https|rsync|sftp|lp)
				;;
			*)
				die "${EBZR}: fetch from ${EBZR_REPO_URI%:*} is not yet implemented."
				;;
		esac
	fi

	if [[ ! -d ${EBZR_STORE_DIR} ]] ; then
		debug-print "${FUNCNAME}: initial branch. creating bzr directory"
		addwrite /
		mkdir -p "${EBZR_STORE_DIR}" \
			|| die "${EBZR}: can't mkdir ${EBZR_STORE_DIR}."
		chmod -f o+rw "${EBZR_STORE_DIR}" \
			|| die "${EBZR}: can't chmod ${EBZR_STORE_DIR}."
		export SANDBOX_WRITE="${SANDBOX_WRITE%%:/}"
	fi

	cd -P "${EBZR_STORE_DIR}" || die "${EBZR}: can't chdir to ${EBZR_STORE_DIR}"

	EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_DIR}"

	addwrite "${EBZR_STORE_DIR}"
	addwrite "${EBZR_BRANCH_DIR}"

	debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"

	local repository

	if [[ ${EBZR_REPO_URI} == */* ]]; then
		repository="${EBZR_REPO_URI}${EBZR_BRANCH}"
	else
		repository="${EBZR_REPO_URI}"
	fi

	if [[ ! -d ${EBZR_BRANCH_DIR} ]] ; then
		# fetch branch
		einfo "bzr branch start -->"
		einfo "   repository: ${repository} => ${EBZR_BRANCH_DIR}"

		${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${EBZR_BRANCH_DIR}" \
			|| die "${EBZR}: can't branch from ${repository}."

	else
		# update branch
		einfo "bzr pull start -->"
		einfo "   repository: ${repository}"

		cd "${EBZR_BRANCH_DIR}"
		${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} "${repository}" \
			|| die "${EBZR}: can't merge from ${repository}."
		${EBZR_DIFFSTAT_CMD}
	fi

	cd "${EBZR_BRANCH_DIR}"

	einfo "exporting ..."
	${EBZR_EXPORT_CMD} ${EBZR_REVISION:+-r ${EBZR_REVISION}} "${WORKDIR}/${P}" \
			|| die "${EBZR}: export failed"

	local revision
	if [[ -n "${EBZR_REVISION}" ]]; then
		revision="${EBZR_REVISION}"
	else
		revision=$(${EBZR_REVNO_CMD} "${EBZR_BRANCH_DIR}")
	fi

	einfo "Revision ${revision} is now in ${WORKDIR}/${P}"

	cd "${WORKDIR}"
}

# @FUNCTION: bzr_bootstrap
# @DESCRIPTION:
# Apply patches in ${EBZR_PATCHES} and run ${EBZR_BOOTSTRAP} if specified
bzr_bootstrap() {
	local patch lpatch

	cd "${S}"

	if [[ -n ${EBZR_PATCHES} ]] ; then
		einfo "apply patches -->"

		for patch in ${EBZR_PATCHES} ; do
			if [[ -f ${patch} ]] ; then
				epatch ${patch}
			else
				for lpatch in "${FILESDIR}"/${patch} ; do
					if [[ -f ${lpatch} ]] ; then
						epatch ${lpatch}
					else
						die "${EBZR}: ${patch} is not found"
					fi
				done
			fi
		done
		echo
	fi

	if [[ -n ${EBZR_BOOTSTRAP} ]] ; then
		einfo "begin bootstrap -->"

		if [[ -f ${EBZR_BOOTSTRAP} ]] && [[ -x ${EBZR_BOOTSTRAP} ]] ; then
			einfo "   bootstrap with a file: ${EBZR_BOOTSTRAP}"
			"./${EBZR_BOOTSTRAP}" \
				|| die "${EBZR}: can't execute EBZR_BOOTSTRAP."
		else
			einfo "   bootstrap with commands: ${EBZR_BOOTSTRAP}"
			"${EBZR_BOOTSTRAP}" \
				|| die "${EBZR}: can't eval EBZR_BOOTSTRAP."
		fi
	fi
}

# @FUNCTION: bzr_src_unpack
# @DESCRIPTION:
# default src_unpack. fetch and bootstrap.
bzr_src_unpack() {
	bzr_fetch || die "${EBZR}: unknown problem in bzr_fetch()."
	bzr_bootstrap || die "${EBZR}: unknown problem in bzr_bootstrap()."
}

Re: [gentoo-dev] Re: bzr.eclass into Portage

[Jonas Bernoulli]

[-- Attachment #1: Type: text/plain, Size: 7992 bytes --]

Here is a patch that adds support for shared repositories. Since bzr
is still a bit slow this is quite useful when using multiple branches.

For example I have modified the live emacs(-cvs) ebuild to use the bzr
mirror of emacs instead of cvs. I also have my own emacs branches, and
sometimes want to install from one of these and at other times from
trunk. Without support for shared repositories this would require the
standalone branches to be manually moved out of the way everytime I
want to switch branches. (Or worse the complete tree to be checked out
from scratch every time I switch branches.)

Please consider these changes

Jonas

--- /usr/local/portage/layman/emacs/eclass/bzr.eclass	2008-10-05
22:40:18.000000000 +0200
+++ /usr/portage/eclass/bzr.eclass	2008-10-05 10:22:12.000000000 +0200
@@ -9,6 +9,7 @@
 # @DESCRIPTION:
 # The bzr.eclass provides support for apps using the bazaar DSCM
(distributed source control management system).
 # The eclass was originally derived from the git eclass.
+# Shared repository support added by Jonas Bernoulli <jonas@bernoulli.cc>.
 #
 # Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
 # this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.
@@ -22,13 +23,23 @@
 HOMEPAGE="http://bazaar-vcs.org/"
 DESCRIPTION="Based on the ${EBZR} eclass"

-DEPEND=">=dev-util/bzr-0.92"
+DEPEND=">=dev-util/bzr-1.6"

 # @ECLASS-VARIABLE: EBZR_STORE_DIR
 # @DESCRIPTION:
 # The dir to store the bzr sources.
 EBZR_STORE_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src"

+# @ECLASS-VARIABLE: EBZR_SHARED_REPO
+# @DESCRIPTION:
+# Whether to use a shared repository (see bzr help repositories).
+EBZR_SHARED_REPO="${EBZR_SHARED_REPO:-}"
+
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_CMD
+# @DESCRIPTION:
+# The bzr command to initialize the shared repository.
+EBZR_INIT_REPO_CMD="bzr init-repo"
+
 # @ECLASS-VARIABLE: EBZR_FETCH_CMD
 # @DESCRIPTION:
 # The bzr command to fetch the sources.
@@ -54,9 +65,24 @@
 # The bzr command to list revision number of the branch.
 EBZR_REVNO_CMD="bzr revno"

+# @ECLASS-VARIABLE: EBZR_INIT_REPO_OPTS
+# @DESCRIPTION:
+# Options passed to the init-repo commands.
+EBZR_INIT_REPO_OPTS="${EBZR_INIT_REPO_OPTS:-}"
+
+# @ECLASS-VARIABLE: EBZR_FETCH_OPTS
+# @DESCRIPTION:
+# Options passed to the fetch commands in additon to EBZR_OPTIONS.
+EBZR_FETCH_OPTS="${EBZR_FETCH_OPTS:-}"
+
+# @ECLASS-VARIABLE: EBZR_UPDATE_OPTS
+# @DESCRIPTION:
+# Options passed to the update commands in additon to EBZR_OPTIONS.
+EBZR_UPDATE_OPTS="${EBZR_UPDATE_OPTS:-}"
+
 # @ECLASS-VARIABLE: EBZR_OPTIONS
 # @DESCRIPTION:
-# The options passed to the fetch and update commands.
+# The common options passed to the fetch and update commands.
 EBZR_OPTIONS="${EBZR_OPTIONS:-}"

 # @ECLASS-VARIABLE: EBZR_REPO_URI
@@ -72,7 +98,7 @@
 # 		- lp://
 # @CODE
 #
-# Note: lp = https://launchpad.net
+# Note: lp = http://launchpad.net
 EBZR_REPO_URI="${EBZR_REPO_URI:-}"

 # @ECLASS-VARIABLE: EBZR_BOOTSTRAP
@@ -93,21 +119,26 @@
 # @ECLASS-VARIABLE: EBZR_BRANCH
 # @DESCRIPTION:
 # The branch to fetch in bzr_fetch().
-#
-# default: trunk
-EBZR_BRANCH="${EBZR_BRANCH:-trunk}"
+EBZR_BRANCH="${EBZR_BRANCH:-}"

 # @ECLASS-VARIABLE: EBZR_REVISION
 # @DESCRIPTION:
 # Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
 EBZR_REVISION="${EBZR_REVISION:-}"

-# @ECLASS-VARIABLE: EBZR_CACHE_DIR
+# @ECLASS-VARIABLE: EBZR_CACHE_REPO_DIR
 # @DESCRIPTION:
-# The dir to store the source for the package, relative to EBZR_STORE_DIR.
+# The dir name of the local shared repository (if any).
 #
 # default: ${PN}
-EBZR_CACHE_DIR="${EBZR_CACHE_DIR:-${PN}}"
+EBZR_CACHE_REPO_DIR="${EBZR_CACHE_REPO_DIR:-}"
+
+# @ECLASS-VARIABLE: EBZR_CACHE_BRANCH_DIR
+# @DESCRIPTION:
+# The dir name of the local branch.
+#
+# default: ${EBZR_BRANCH} when using a shared repository or ${PN} otherwise
+EBZR_CACHE_BRANCH_DIR="${EBZR_CACHE_BRANCH_DIR:-}"

 # @FUNCTION: bzr_fetch
 # @DESCRIPTION:
@@ -143,37 +174,64 @@

 	cd -P "${EBZR_STORE_DIR}" || die "${EBZR}: can't chdir to ${EBZR_STORE_DIR}"

-	EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_DIR}"
-
 	addwrite "${EBZR_STORE_DIR}"
-	addwrite "${EBZR_BRANCH_DIR}"

-	debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"
+	if [[ -n ${EBZR_SHARED_REPO} ]]; then
+		# using shared repository
+		EBZR_REPO_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_REPO_DIR:-${PN}}"
+		EBZR_BRANCH_DIR="${EBZR_REPO_DIR}/${EBZR_CACHE_BRANCH_DIR:-${EBZR_BRANCH}}"
+
+		addwrite "${EBZR_REPO_DIR}"
+	else
+		# using stand-alone branch
+		EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_BRANCH_DIR:-${PN}}"
+	fi
+
+	addwrite "${EBZR_BRANCH_DIR}"

-	local repository
+	local branch

-	if [[ ${EBZR_REPO_URI} == */* ]]; then
-		repository="${EBZR_REPO_URI}${EBZR_BRANCH}"
+	if [[ -n ${EBZR_BRANCH} ]] ; then
+		branch="${EBZR_REPO_URI}/${EBZR_BRANCH}"
 	else
-		repository="${EBZR_REPO_URI}"
+		branch="${EBZR_REPO_URI}"
+	fi
+
+	if [[ ${EBZR_SHARED_REPO} && ! -d ${EBZR_REPO_DIR} ]] ; then
+		# create shared repository
+		debug-print "${FUNCNAME}: EBZR_INIT_REPO_OPTS = ${EBZR_INIT_REPO_OPTS}"
+
+		${EBZR_INIT_REPO_CMD} ${EBZR_INIT_REPO_OPTS} ${EBZR_REPO_DIR} \
+			|| die "${EBZR}: can't initialize shared repository."
+	fi
+
+	if [[ ${EBZR_BRANCH} == */* && ! -f $(dirname ${EBZR_BRANCH}) ]]; then
+		# prepare path to branch
+		mkdir -p "${EBZR_REPO_DIR}/$(dirname ${EBZR_BRANCH})"
 	fi

 	if [[ ! -d ${EBZR_BRANCH_DIR} ]] ; then
 		# fetch branch
 		einfo "bzr branch start -->"
-		einfo "   repository: ${repository} => ${EBZR_BRANCH_DIR}"
+		einfo "   branch: ${branch} => ${EBZR_BRANCH_DIR}"
+
+		EBZR_OPTIONS="${EBZR_OPTIONS} ${EBZR_FETCH_OPTS}"
+		debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"

-		${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${EBZR_BRANCH_DIR}" \
-			|| die "${EBZR}: can't branch from ${repository}."
+		${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${branch}" "${EBZR_BRANCH_DIR}" \
+			|| die "${EBZR}: can't branch from ${branch}."

 	else
 		# update branch
 		einfo "bzr pull start -->"
-		einfo "   repository: ${repository}"
+		einfo "   branch: ${branch} => ${EBZR_BRANCH_DIR}"
+
+		EBZR_OPTIONS="${EBZR_OPTIONS} ${EBZR_UPDATE_OPTS}"
+		debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"

 		cd "${EBZR_BRANCH_DIR}"
-		${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} "${repository}" \
-			|| die "${EBZR}: can't merge from ${repository}."
+		${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} "${branch}" \
+			|| die "${EBZR}: can't merge from ${branch}."
 		${EBZR_DIFFSTAT_CMD}
 	fi

On Sun, Oct 5, 2008 at 7:26 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Fri, 21 Mar 2008, Christian Faulhammer wrote:
>
>> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>:
>>> With the help of Ingmar we did some cleanup and added support for
>>> eclass-manpages at
>>> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr.
>>> I'll be moving the updated eclass to the master branch, testing and
>>> asking users to try it out during this weekend.
>>> This eclass is used in the overlay for the live
>>> avant-window-navigator ebuilds, so it's probably not as used/tested
>>> as the remaining packages. It has provided us the support we needed
>>> for awn, but you might need additional features or to review existing
>>> ones. Please test the updated eclass on your overlay, feel free to
>>> maintain it and, when you think its ready, add it to the tree. When
>>> you do so, I'll remove it from our overlay and we'll use the eclass
>>> on the tree.
>
>>  We have a prior version for some time now in the Emacs overlay for
>> two live ebuilds...so we go and merge your changed (ulm already
>> did), test it and report any problems.
>
> As I just learned there are (at least) three overlays using
> bzr.eclass, namely desktop-effects, emacs, and ltsp.
>
> So I think it is justified to move bzr.eclass to the Portage tree.
> Currect version of bzr.eclass is attached.
>
> Please raise your objections *now*.
>
> Ulrich

[-- Attachment #2: bzr.eclass.patch --]
[-- Type: application/octet-stream, Size: 5883 bytes --]

--- /usr/local/portage/layman/emacs/eclass/bzr.eclass	2008-10-05 22:40:18.000000000 +0200
+++ /usr/portage/eclass/bzr.eclass	2008-10-05 10:22:12.000000000 +0200
@@ -9,6 +9,7 @@
 # @DESCRIPTION:
 # The bzr.eclass provides support for apps using the bazaar DSCM (distributed source control management system).
 # The eclass was originally derived from the git eclass.
+# Shared repository support added by Jonas Bernoulli <jonas@bernoulli.cc>.
 #
 # Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
 # this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.
@@ -22,13 +23,23 @@
 HOMEPAGE="http://bazaar-vcs.org/"
 DESCRIPTION="Based on the ${EBZR} eclass"
 
-DEPEND=">=dev-util/bzr-0.92"
+DEPEND=">=dev-util/bzr-1.6"
 
 # @ECLASS-VARIABLE: EBZR_STORE_DIR
 # @DESCRIPTION:
 # The dir to store the bzr sources.
 EBZR_STORE_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src"
 
+# @ECLASS-VARIABLE: EBZR_SHARED_REPO
+# @DESCRIPTION:
+# Whether to use a shared repository (see bzr help repositories).
+EBZR_SHARED_REPO="${EBZR_SHARED_REPO:-}"
+
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_CMD
+# @DESCRIPTION:
+# The bzr command to initialize the shared repository.
+EBZR_INIT_REPO_CMD="bzr init-repo"
+
 # @ECLASS-VARIABLE: EBZR_FETCH_CMD
 # @DESCRIPTION:
 # The bzr command to fetch the sources.
@@ -54,9 +65,24 @@
 # The bzr command to list revision number of the branch.
 EBZR_REVNO_CMD="bzr revno"
 
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_OPTS
+# @DESCRIPTION:
+# Options passed to the init-repo commands.
+EBZR_INIT_REPO_OPTS="${EBZR_INIT_REPO_OPTS:-}"
+
+# @ECLASS-VARIABLE: EBZR_FETCH_OPTS
+# @DESCRIPTION:
+# Options passed to the fetch commands in additon to EBZR_OPTIONS.
+EBZR_FETCH_OPTS="${EBZR_FETCH_OPTS:-}"
+
+# @ECLASS-VARIABLE: EBZR_UPDATE_OPTS
+# @DESCRIPTION:
+# Options passed to the update commands in additon to EBZR_OPTIONS.
+EBZR_UPDATE_OPTS="${EBZR_UPDATE_OPTS:-}"
+
 # @ECLASS-VARIABLE: EBZR_OPTIONS
 # @DESCRIPTION:
-# The options passed to the fetch and update commands.
+# The common options passed to the fetch and update commands.
 EBZR_OPTIONS="${EBZR_OPTIONS:-}"
 
 # @ECLASS-VARIABLE: EBZR_REPO_URI
@@ -72,7 +98,7 @@
 # 		- lp://
 # @CODE
 #
-# Note: lp = https://launchpad.net
+# Note: lp = http://launchpad.net
 EBZR_REPO_URI="${EBZR_REPO_URI:-}"
 
 # @ECLASS-VARIABLE: EBZR_BOOTSTRAP
@@ -93,21 +119,26 @@
 # @ECLASS-VARIABLE: EBZR_BRANCH
 # @DESCRIPTION:
 # The branch to fetch in bzr_fetch().
-#
-# default: trunk
-EBZR_BRANCH="${EBZR_BRANCH:-trunk}"
+EBZR_BRANCH="${EBZR_BRANCH:-}"
 
 # @ECLASS-VARIABLE: EBZR_REVISION
 # @DESCRIPTION:
 # Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
 EBZR_REVISION="${EBZR_REVISION:-}"
 
-# @ECLASS-VARIABLE: EBZR_CACHE_DIR
+# @ECLASS-VARIABLE: EBZR_CACHE_REPO_DIR
 # @DESCRIPTION:
-# The dir to store the source for the package, relative to EBZR_STORE_DIR.
+# The dir name of the local shared repository (if any).
 #
 # default: ${PN}
-EBZR_CACHE_DIR="${EBZR_CACHE_DIR:-${PN}}"
+EBZR_CACHE_REPO_DIR="${EBZR_CACHE_REPO_DIR:-}"
+
+# @ECLASS-VARIABLE: EBZR_CACHE_BRANCH_DIR
+# @DESCRIPTION:
+# The dir name of the local branch.
+#
+# default: ${EBZR_BRANCH} when using a shared repository or ${PN} otherwise
+EBZR_CACHE_BRANCH_DIR="${EBZR_CACHE_BRANCH_DIR:-}"
 
 # @FUNCTION: bzr_fetch
 # @DESCRIPTION:
@@ -143,37 +174,64 @@
 
 	cd -P "${EBZR_STORE_DIR}" || die "${EBZR}: can't chdir to ${EBZR_STORE_DIR}"
 
-	EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_DIR}"
-
 	addwrite "${EBZR_STORE_DIR}"
-	addwrite "${EBZR_BRANCH_DIR}"
 
-	debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"
+	if [[ -n ${EBZR_SHARED_REPO} ]]; then
+		# using shared repository
+		EBZR_REPO_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_REPO_DIR:-${PN}}"
+		EBZR_BRANCH_DIR="${EBZR_REPO_DIR}/${EBZR_CACHE_BRANCH_DIR:-${EBZR_BRANCH}}"
+
+		addwrite "${EBZR_REPO_DIR}"
+	else
+		# using stand-alone branch
+		EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_BRANCH_DIR:-${PN}}"
+	fi
+
+	addwrite "${EBZR_BRANCH_DIR}"
 
-	local repository
+	local branch
 
-	if [[ ${EBZR_REPO_URI} == */* ]]; then
-		repository="${EBZR_REPO_URI}${EBZR_BRANCH}"
+	if [[ -n ${EBZR_BRANCH} ]] ; then
+		branch="${EBZR_REPO_URI}/${EBZR_BRANCH}"
 	else
-		repository="${EBZR_REPO_URI}"
+		branch="${EBZR_REPO_URI}"
+	fi
+
+	if [[ ${EBZR_SHARED_REPO} && ! -d ${EBZR_REPO_DIR} ]] ; then
+		# create shared repository
+		debug-print "${FUNCNAME}: EBZR_INIT_REPO_OPTS = ${EBZR_INIT_REPO_OPTS}"
+
+		${EBZR_INIT_REPO_CMD} ${EBZR_INIT_REPO_OPTS} ${EBZR_REPO_DIR} \
+			|| die "${EBZR}: can't initialize shared repository."
+	fi
+
+	if [[ ${EBZR_BRANCH} == */* && ! -f $(dirname ${EBZR_BRANCH}) ]]; then
+		# prepare path to branch
+		mkdir -p "${EBZR_REPO_DIR}/$(dirname ${EBZR_BRANCH})"
 	fi
 
 	if [[ ! -d ${EBZR_BRANCH_DIR} ]] ; then
 		# fetch branch
 		einfo "bzr branch start -->"
-		einfo "   repository: ${repository} => ${EBZR_BRANCH_DIR}"
+		einfo "   branch: ${branch} => ${EBZR_BRANCH_DIR}"
+
+		EBZR_OPTIONS="${EBZR_OPTIONS} ${EBZR_FETCH_OPTS}"
+		debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"
 
-		${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${EBZR_BRANCH_DIR}" \
-			|| die "${EBZR}: can't branch from ${repository}."
+		${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${branch}" "${EBZR_BRANCH_DIR}" \
+			|| die "${EBZR}: can't branch from ${branch}."
 
 	else
 		# update branch
 		einfo "bzr pull start -->"
-		einfo "   repository: ${repository}"
+		einfo "   branch: ${branch} => ${EBZR_BRANCH_DIR}"
+
+		EBZR_OPTIONS="${EBZR_OPTIONS} ${EBZR_UPDATE_OPTS}"
+		debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"
 
 		cd "${EBZR_BRANCH_DIR}"
-		${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} "${repository}" \
-			|| die "${EBZR}: can't merge from ${repository}."
+		${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} "${branch}" \
+			|| die "${EBZR}: can't merge from ${branch}."
 		${EBZR_DIFFSTAT_CMD}
 	fi
 

Re: [gentoo-dev] Re: bzr.eclass into Portage

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ulrich.

Ulrich Mueller wrote:
>>>>>> On Fri, 21 Mar 2008, Christian Faulhammer wrote:
> 
>> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>:
>>> With the help of Ingmar we did some cleanup and added support for 
>>> eclass-manpages at 
>>> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr. 
>>> I'll be moving the updated eclass to the master branch, testing and 
>>> asking users to try it out during this weekend.
>>> This eclass is used in the overlay for the live
>>> avant-window-navigator ebuilds, so it's probably not as used/tested
>>> as the remaining packages. It has provided us the support we needed
>>> for awn, but you might need additional features or to review existing
>>> ones. Please test the updated eclass on your overlay, feel free to
>>> maintain it and, when you think its ready, add it to the tree. When
>>> you do so, I'll remove it from our overlay and we'll use the eclass
>>> on the tree.
> 
>>  We have a prior version for some time now in the Emacs overlay for
>> two live ebuilds...so we go and merge your changed (ulm already
>> did), test it and report any problems.
> 
> As I just learned there are (at least) three overlays using
> bzr.eclass, namely desktop-effects, emacs, and ltsp.
> 
> So I think it is justified to move bzr.eclass to the Portage tree.
> Currect version of bzr.eclass is attached.
> 
> Please raise your objections *now*.

No objections here, just a question. Do you know if the issue with the
lp:// sources has been fixed in bzr?
I'll be waiting for the commit to remove the eclass from the
desktop-effects overlay.

> Ulrich
> 
> 

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjpYrcACgkQcAWygvVEyAI3lwCZAfnVwW9RWALkXOINwaCbdxgg
QIsAn2noprlga9qzUtFtwIRZk8ew9ia+
=9xKc
-----END PGP SIGNATURE-----

[gentoo-dev] Re: bzr.eclass into Portage

[Ulrich Mueller]

>>>>> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote:

> No objections here, just a question. Do you know if the issue with the
> lp:// sources has been fixed in bzr?

Looks like this is working fine with bzr-1.5, so I'll change the
dependency.

Ulrich

[gentoo-dev] Re: bzr.eclass into Portage

[Steve Long]

Ulrich Mueller wrote:

>>>>>> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote:
> 
>> No objections here, just a question. Do you know if the issue with the
>> lp:// sources has been fixed in bzr?
>
No objections, a minor point wrt bash:

EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
doesn't do anything (beyond waste lex and yacc time.) I can understand the
maintenance argument, but I don't think it really flies, given the
inordinate lengths considered in the past to avoid sourcing an ebuild.

The same consideration applies to all those "constant values" 'and indeed'
${foo} as opposed to $foo, though first time I raised that I got sworn at,
so not expecting miracles here.

[[ -z ${EBZR_REPO_URI} ]] && die ..
Here's how I'd write that:
[[ $EBZR_REPO_URI ]] || die ..

I've heard the "be explicit" argument before (hey antarus;) and here's why I
disagree:
If you don't know test (''help test'') and what its default is, then you
really don't know the basics of shellscript (you possibly only think you
do.) If you don't know shell, and can't begin to understand what that might
do, then you shouldn't consider coding as a career, and I'd expect you to
take quite a while to go through the #bash crucible; if you ever make it
I'd have a lot of time for you.

(Since you use || elsewhere, I don't expect to hear the "|| is cryptic even
if we say OR in speech" argument.)

I appreciate that appears like 3 or 4 points: they all come under the 'clean
bash' heading: it runs faster, as well as being easier to read and write.

> Looks like this is working fine with bzr-1.5, so I'll change the
> dependency.
> 
Given that, is there any reason not to use 1.6 if installed, and fallback to
an earlier version if not? Personally I'd just use an unversioned dep in
the latter case, given that 1.5 is stable and 1.7.1 is ~arch (amd64).
Doesn't sound like it's going to be long to get 1.6.

I'm thinking: "maximise utility before you unleash it on the tree".

[gentoo-dev] Re: bzr.eclass into Portage

[Ulrich Mueller]

>>>>> On Mon, 13 Oct 2008, Steve Long wrote:

> No objections, a minor point wrt bash:

> EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
> doesn't do anything (beyond waste lex and yacc time.)

It does something, namely assigns an empty string if the variable was
undefined before. ;-) git.eclass and mercurial.eclass do
: ${EGIT_OPTIONS:=}
which has the same effect.

I've left these statements in for now, since I don't see how they
could harm. Does anyone else have an opinion here? I'm not really
decided about this point.

> [[ -z ${EBZR_REPO_URI} ]] && die ..
> Here's how I'd write that:
> [[ $EBZR_REPO_URI ]] || die ..

Applied. (However, I didn't remove the curly braces which are Gentoo
"house style".)

> I've heard the "be explicit" argument before (hey antarus;) and
> here's why I disagree:
> If you don't know test (''help test'') and what its default is, then
> you really don't know the basics of shellscript (you possibly only
> think you do.) If you don't know shell, and can't begin to
> understand what that might do, then you shouldn't consider coding as
> a career, and I'd expect you to take quite a while to go through the
> #bash crucible; if you ever make it I'd have a lot of time for you.

Don't use a sledgehammer to crack a nut. The above is purely a
question of coding style and personal preferences.

> Given that, is there any reason not to use 1.6 if installed, and
> fallback to an earlier version if not?

Of course not. The dependency is DEPEND=">=dev-util/bzr-1.5".

Ulrich

Re: [gentoo-dev] Re: bzr.eclass into Portage

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Monday 13 October 2008 04:43:48 Steve Long wrote:
> EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
> doesn't do anything (beyond waste lex and yacc time.)

It gets listed in the generated man page.

[...]
> The same consideration applies to all those "constant values" 'and indeed'
> ${foo} as opposed to $foo, though first time I raised that I got sworn at,
> so not expecting miracles here.

Are you for real?

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Re: bzr.eclass into Portage

[Steve Long]

Bo Ørsted Andresen wrote:

> On Monday 13 October 2008 04:43:48 Steve Long wrote:
>> EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
>> doesn't do anything (beyond waste lex and yacc time.)
> 
> It gets listed in the generated man page.
>
From what I remember of the awk that generates those manpages, this:
 
# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
# The options passed to the fetch and update commands.

..does that.

>> The same consideration applies to all those "constant values" 'and
>> indeed' ${foo} as opposed to $foo, though first time I raised that I got
>> sworn at, so not expecting miracles here.
> 
> Are you for real?
> 
Perhaps you missed the discussion about EAPI in filenames?

Re: [gentoo-dev] Re: bzr.eclass into Portage

[Ulrich Mueller]

>>>>> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote:

> Ulrich Mueller wrote:
>> As I just learned there are (at least) three overlays using
>> bzr.eclass, namely desktop-effects, emacs, and ltsp.
>> 
>> So I think it is justified to move bzr.eclass to the Portage tree.

> I'll be waiting for the commit to remove the eclass from the
> desktop-effects overlay.

Committed to Portage tree today.

Ulrich