When installing with paludis' "cave resolve" as user root, dev-lang/scala-2.10.2 tries to create /root/.m2/repository. Paludis doesn't allow this, probably for security reasons, and fails (see attached output). Note that, in contrast, installing with portage's "emerge" creates .m2/repository in the package manager's temporary directory, i.e. in /var/tmp/portage/.m2/repository – but, strangely, on top level, not in some ebuild-specific subdirectory. (Note that the default temporary directory of paludis is /var/tmp/paludis.) I finally managed to install scala-2.10.2 with the following workaround. I'm not sure whether every step of the following list is necessary, but in any case it worked. 1. suspend the installation at the start of src_compile 2. create the directory /var/tmp/paludis/dev-lang-scala-2.10.2/temp/.m2, chown it to paludisbuild:paludisbuild 3. create /root/.m2 as a symlink to the directory just created 4. continue the installation process Reproducible: Always
Created attachment 356790 [details] output of "cave resolve"
Created attachment 356792 [details] output of "cave resolve"
BTW, this attachment (https://482192.bugs.gentoo.org/attachment.cgi?id=356732) to bug 482192 proves that, when installed with emerge, this ebuild creates /var/tmp/portage/.m2/repository.
Thanks for the reports, sorry I did not notice it was doing this earlier.
scala-2.9.2 works fine, though it require icedtea-6
I patched the build.xml and tweaked the ebuild, and committed my changes to portage: Fix: bug 482192 - thanks to Christian Strahl, Mike Limansky and Sumit Khanna for reporting; bug 482260 - thanks to Christoph Lange for reporting; bug 482286 I think this should fix the problem. I don't use paludis though, so it would be neat if you could please test.
(In reply to Mark Wright from comment #6) > I patched the build.xml and tweaked the ebuild, and committed my changes to > portage: > > … > > I think this should fix the problem. I don't use paludis though, so it would > be neat if you could please test. Thanks, it worked for me. Just one thing: shouldn't a changed ebuild be given a different version number, ...-r1?
(In reply to Christoph Lange from comment #7) > (In reply to Mark Wright from comment #6) > > I patched the build.xml and tweaked the ebuild, and committed my changes to > > portage: > > > > … > > > > I think this should fix the problem. I don't use paludis though, so it would > > be neat if you could please test. > > Thanks, it worked for me. Just one thing: shouldn't a changed ebuild be > given a different version number, ...-r1? Thanks for testing. It is usually not necessary to rev bump a changed ebuild (the -r1) when it is fixing a compilation problem. It usually is best to rev bump an ebuild that uses subslot depends, as this one does, when changing the dependencies. As not doing so can confuse emerge when upgrading packages later. I did add 2 dependencies. It takes a while to build scala, and the only ebuild that actually uses a subslot depend on scala, sci-mathematics/isabelle, is not in the tree yet, I am going to add it now. I think its best not to force a rebuild on users who already have it installed.
(In reply to Mark Wright from comment #8) > It is usually not necessary to rev bump a changed ebuild > (the -r1) when it is fixing a compilation problem. > […] Thanks for explaining the background. I am not quite so experienced with this yet, and your explanation gave me a better understanding of these matters.