configure stops and outputs the following, when you emerge bristol: ... checking dependency style of i486-pc-linux-gnu-gcc... (cached) none checking whether make sets $(MAKE)... (cached) yes ************************************************************* * * * A previous bristol installation exists on this system. * * * * If you have bristol installed from your package manager * * you really need to remove it first. If you have it from * * a previous bristol build then you can remove it with a * * 'make uninstall' from the previous build dir. * * * * If you understand the risks or just want to be lazy then * * you can override this test with --disable-version-check * * however the author advises against such a workaround. * * * ************************************************************* The problem appears when you update bristol. In my case pretend looks like this: # emerge -pvu bristol These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] media-sound/bristol-0.60.9 [0.60.7] USE="alsa -oss -static-libs% (-X%*)" 0 kB [1=>0] Total: 1 package (1 upgrade), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/pro-audio Reproducible: Always Steps to Reproduce: emerge a newer version of bristol over an older one. Actual Results: configure stops Expected Results: configure, build, install of newer version I think --disabl-verision-check can solve the problem, however i do not now enough about the gentoo/portage way to decide this.
Created attachment 292755 [details] build.log (some color-codes stripped) build.log of emerge media-sound/bristol-0.60.9
(In reply to comment #0) > I think --disable-verision-check can solve the problem, however i do not now > enough about the gentoo/portage way to decide this. I think that should work for us without having to resort to blocking unless upstream is foolish enough to let previous installs affect new builds, but I haven't tested for that explicitly. Fixed in CVS.
