>>> Emerging (1 of 1) app-vim/youcompleteme-99999999 >>> Unpacking source... * Fetching HEAD from git://github.com/Valloric/YouCompleteMe.git ... /var/tmp/portage/app-vim/youcompleteme-99999999/temp/environment: line 2528: git: command not found it seems all ebuilds currently using git-r3 are affected
/var/cvsroot/gentoo-x86/eclass/git-r3.eclass,v <-- git-r3.eclass new revision: 1.13; previous revision: 1.12 Added.
This break stable ARCH as there is no >=dev-vcs/git-1.8.2.1 stable. Last stable is 1.8.1.5
(In reply to Bertrand Jacquin from comment #2) > This break stable ARCH as there is no >=dev-vcs/git-1.8.2.1 stable. > > Last stable is 1.8.1.5 And which package using this eclass is stable? If you mix stable with non-stable, you have to be able to handle the fallout.
(In reply to Michał Górny from comment #3) > (In reply to Bertrand Jacquin from comment #2) > > This break stable ARCH as there is no >=dev-vcs/git-1.8.2.1 stable. > > > > Last stable is 1.8.1.5 > > And which package using this eclass is stable? If you mix stable with > non-stable, you have to be able to handle the fallout. true :) Sorry for noise
(In reply to Bertrand Jacquin from comment #4) > (In reply to Michał Górny from comment #3) > > (In reply to Bertrand Jacquin from comment #2) > > > This break stable ARCH as there is no >=dev-vcs/git-1.8.2.1 stable. > > > > > > Last stable is 1.8.1.5 > > > > And which package using this eclass is stable? If you mix stable with > > non-stable, you have to be able to handle the fallout. > > true :) Sorry for noise It is not true. There is no policy that says that we should ignore the possibility that 9999 packages can be installed on stable arch. This is just, because the maintainer of the eclass didn't think of it in the first place and now doesn't care to fix.
but anyway... unmasking latest git should really be fine.
I just got bit by this. I shouldn't be forced to use ~arch git because I am using live ebuilds when the git eclass doesn't depend on features in ~arch git. Please adjust the dependency. Thanks, William
Created attachment 360284 [details, diff] git-r3.patch This patch will fix the issue. Thanks, William
(In reply to William Hubbs from comment #8) > Created attachment 360284 [details, diff] [details, diff] > git-r3.patch > > This patch will fix the issue. > > Thanks, > > William That will not work consistently, see bug 487018
(In reply to William Hubbs from comment #7) > I just got bit by this. I shouldn't be forced to use ~arch git because I > am using live ebuilds when the git eclass doesn't depend on features in > ~arch git. > > Please adjust the dependency. It requires --unshallow that is not available 1.8.1.5.
(In reply to Michał Górny from comment #10) > (In reply to William Hubbs from comment #7) > > I just got bit by this. I shouldn't be forced to use ~arch git because I > > am using live ebuilds when the git eclass doesn't depend on features in > > ~arch git. > > > > Please adjust the dependency. > > It requires --unshallow that is not available 1.8.1.5. Are you sure it requires this? It hasn't seened to cause issues here with latest stable git.
Yes. This happens e.g. when you use the same repo as EGIT_REPO_URI for one package, and a submodule for another one. Or when you disable shallow clones at some point.
Ok, that's all I needed to know. :-)
FWIW the git-2 eclass includes this tidbit: # (since we override src_unpack this doesn't hurt) inherit git-r3 And we know that from the above discussion that git-r3 depends on >=dev-vcs/git-1.8.2.1, for which no versions are marked as stable. This means that any ebuilds which currently inherit git-2 (stable, or not) will force the user to unmask dev-vcs/git to proceed.
(In reply to Mina Naguib from comment #14) > FWIW the git-2 eclass includes this tidbit: > > # (since we override src_unpack this doesn't hurt) > inherit git-r3 Fixed this one. Now git-r3 should require the new git only.
