Bug 638546 – git-r3 lacks default fetch/unpack method and does not fetch SRI_URI

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Joakim Tjernlund 2017-11-23 08:54:29 UTC]

I have this in my git-r3 ebuild:
	inherit git-r3
	EGIT_REPO_URI="https://github.com/TigerVNC/tigervnc.git"
	EGIT_BRANCH="master"
	SRC_URI="https://dev.gentoo.org/~armin76/dist/tigervnc-1.4.2-patches-0.1.tar.bz2
	server? ( ftp://ftp.freedesktop.org/pub/xorg/individual/xserver/xorg-server-${XSERVER_VERSION}.tar.bz2)"

SRC_URI is not fetched/unpacked by git-r3

To overcome this I did this hack:
src_unpack() {
	if [[ ${PV} == *9999* ]]; then
		git-r3_fetch
		git-r3_checkout
	fi
	default
}

Note that git-r3 lacks a default method for both fetch and unpack as well.

[Comment 1 Michał Górny 2017-11-23 18:13:09 UTC]

This is by design. The basic problem is that default_src_unpack is not idempotent, so calling it multiple times causes unpredictable results. For example, if you needed to use git & svn, and both eclasses called 'default', the function would be called twice with undefined result. To avoid this problem, I've made git-r3 not call it and require user to explicitly call 'default' once if necessary.

Thinking about it now, it might have been the wrong choice. After all, git-r3 provides the explicit fetch/checkout functions which could be used to avoid the implicit 'default' call whenever necessary. However, I don't think we can change that now as that would break ebuild that rely on the current behavior and e.g. call 'default' explicitly.

This may be something to be fixed in EAPI 7. However, I'm not sure if introducing such a change wouldn't be more confusing than keeping the current behavior for all EAPIs.

[Comment 2 Joakim Tjernlund 2017-11-23 18:16:49 UTC]

Even not fetching SRC_URI? That feels like a bug.
In earlier git/svn ebuilds I always had to set SRC_URI="" to
avoid downloading.

[Comment 3 Michał Górny 2017-11-23 18:31:10 UTC]

...and you should still be doing that. SRC_URI is fetched and required independently of whether it is actually unpacked.

Not unpacking files can be fixed easily, and the existing ebuilds already rely on that behavior. Calling 'default' twice is not easy to fix, nor easy to notice.

[Comment 4 Joakim Tjernlund 2017-11-23 18:35:41 UTC]

(In reply to Michał Górny from comment #3)
> ...and you should still be doing that. SRC_URI is fetched and required
> independently of whether it is actually unpacked.
> 
> Not unpacking files can be fixed easily, and the existing ebuilds already
> rely on that behavior. Calling 'default' twice is not easy to fix, nor easy
> to notice.

My complaint is that git-r3 does NOT fetch/unpack SRC_URI
Which is why I had specify a src_unpack() at all.

[Comment 5 Michał Górny 2017-11-23 18:48:50 UTC]

Then your complaint is invalid.

Firstly, git-r3 is not responsible for fetching SRC_URI. The PM does that independently of it.

Secondly, defining src_unpack() is a normal ebuild practice. Having to define it is not a bug. It's how the API of this eclass is defined.

[Comment 6 Joakim Tjernlund 2017-11-23 19:01:04 UTC]

(In reply to Michał Górny from comment #5)
> Then your complaint is invalid.
> 
> Firstly, git-r3 is not responsible for fetching SRC_URI. The PM does that
> independently of it.

It does actually fetch SRC_URI, sorry I missed that.

> 
> Secondly, defining src_unpack() is a normal ebuild practice. Having to
> define it is not a bug. It's how the API of this eclass is defined.

But as soon as I inherit git-r3 there is no unpack of SRC_URI, how is
that OK?

[Comment 7 Michał Górny 2017-11-23 19:06:06 UTC]

I'm sorry but explaining eclass basics is beyond the scope of bug reports. Please direct your questions to appropriate ebuild development support channels such as #gentoo-dev-help.