Using bzr branch --stacked instead of bzr export will use no more space in $WORKDIR and will permit the packages’s build systems to better report the details of what version is installed. As an example, GNU Emacs has an emacs-bzr-version variable which would help app-editors/emacs-vcs users report any emacs bugs they encounter upstream. As it is, one needs to know that EBZR_REVNO is set in the build environment and to look for it in /var/db/pkg/. The git-2 eclass does something similar. This has proved beneficial when dealing with upstreams.
I believe that export is the right command to use. The exported tree looks like what one would get from unpacking a tarball; especially, there should be no need for a .bzr directory. Also bzr branch (or bzr checkout) is significantly slower than bzr export. Concerning Emacs, our live ebuilds are passing EBZR_BRANCH and EBZR_REVNO to configure, so that they're available in the system-configuration-options variable.
> The exported tree looks like what one would get from unpacking a tarball Which is exactly why export is the *wrong* choice. Live builds should look like checkouts to the packages’s build systems.
> Concerning Emacs, our live ebuilds are passing EBZR_BRANCH and EBZR_REVNO to > configure, so that they're available in the system-configuration-options > variable. emacs-bzr-version needs the info, too. It gets it by recognizing the tree as a bzr branch. Emacs was only one example. The fix for this issue in the git eclasses was very welcome and helpful when it was done. bzr.eclass should get this right, too.
Still, if we decide to do this, we should use a lightweight checkout, not a branch. Commands like "bzr revno" or "bzr testament" also work for checkouts, and that's all that should be needed. There could be issues with the sandbox too. bzr.eclass does addwrite ${EBZR_STORE_DIR}, but certainly the package's build system shouldn't write to that location.
Hm, would have been nice if the ebuild could simply redefine EBZR_EXPORT_CMD. However, bzr commands lack uniformity in their arguments: bzr branch <src> <dest> bzr checkout <src> <dest> bzr export <dest> <src>
I did suggest bzr branch --stacked, which uses the branch in DISTDIR for the .bzr data, yes? At least my intent was bzr’s equivalent to git’s «clone -l -s».
> but certainly the package's build system shouldn't write to [${EBZR_STORE_DIR}] agreed.
(In reply to comment #6) > I did suggest bzr branch --stacked, which uses the branch in DISTDIR for the > .bzr data, yes? > At least my intent was bzr’s equivalent to git’s «clone -l -s». There's no exact correspondence between git and bzr commands, so it's difficult to say which one matches it better. And a lightweight checkout is slightly smaller. I've added experimental support to bzr.eclass in the Emacs overlay: <http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/bzr.eclass> The feature can be enabled by setting EBZR_WORKDIR_CHECKOUT to a non-empty value, so the default (i.e. using export) isn't changed. There's also emacs-vcs-24.2.9999.ebuild in the overlay which can be used for testing. (emacs-bzr-version is properly initialised, it seems.)
I’m still compiling, but those looks good.
Updated bzr.eclass and app-editors/emacs-vcs ebuild committed to Portage tree. Thank you for bringing this up. Should we use this bug as tracker for package updates? Otherwise, I'll close it.
