The new javatoolkit-0.3.0-r7 has a problem in installing the files in the wrong path... namely /""/.... The line 36: install-scripts = "${EPREFIX}"/usr/$(get_libdir)/${PN}/bin should be without the quotes: install-scripts = ${EPREFIX}/usr/$(get_libdir)/${PN}/bin
Fixed. Thanks for the report. *javatoolkit-0.3.0-r8 (31 Jul 2012) 31 Jul 2012; Ralph Sennhauser <sera@gentoo.org> -javatoolkit-0.3.0-r7.ebuild, +javatoolkit-0.3.0-r8.ebuild: Don't quote EPRIFIX, Portage doesn't like it. Thanks to PhobosK <phobosk@fastmail.fm>. #429092 @dev-portage: Only Portage is affected. Shouldn't /""/ be normalized?
Given that the ebuild doesn't support ANY Gentoo Prefix platforms, I haven't a clue why you are even adding $EPREFIX to the ebuild. That above point withstanding, it is legal for EPREFIX to contain spaces, take care.
(In reply to comment #1) > @dev-portage: Only Portage is affected. Shouldn't /""/ be normalized? Well, it's none of Portage's business if a package installs strange directory names containing quotes. It seems that the real problem is that the setup.cfg interpreter does not remove those quotes like a shell would. According to python's configparser documentation, spaces are allowed in values, with no need for quoting: http://docs.python.org/dev/library/configparser.html#supported-ini-file-structure
(In reply to comment #2) > Given that the ebuild doesn't support ANY Gentoo Prefix platforms, I haven't > a clue why you are even adding $EPREFIX to the ebuild. > Keywords aren't the upper limit of what is allowed to be supported in an ebuild. If there are things that need to be fixed for use in Prefix please file bugs. > That above point withstanding, it is legal for EPREFIX to contain spaces, > take care. repoman complained so I added the quotes last minute even if unnecessary here and only tested in Paludis afterwards. They were not only unnecessary but actually wrong. Usually stuff breaks in Paludis first. Bad luck.
(In reply to comment #3) > (In reply to comment #1) > > @dev-portage: Only Portage is affected. Shouldn't /""/ be normalized? > > Well, it's none of Portage's business if a package installs strange > directory names containing quotes. It seems that the real problem is that > the setup.cfg interpreter does not remove those quotes like a shell would. > According to python's configparser documentation, spaces are allowed in > values, with no need for quoting: > > http://docs.python.org/dev/library/configparser.html#supported-ini-file- > structure Thanks, well, there is this difference, one package manager passes it though a shell, the other not. If you think Portages behavior is desirable then we can close here. Thanks again everyone.
(In reply to comment #4) > (In reply to comment #2) > > Given that the ebuild doesn't support ANY Gentoo Prefix platforms, I haven't > > a clue why you are even adding $EPREFIX to the ebuild. > > > > Keywords aren't the upper limit of what is allowed to be supported in an > ebuild. If there are things that need to be fixed for use in Prefix please > file bugs. Well, that is my point, Ralph. There is nothing to be fixed in the ebuild for Gentoo Prefix because the ebuild doesn't need any Gentoo Prefix compat vars. If anything, we can argue that this bug wouldn't exist if you didn't try to be helpful :) So, thanks for being forward looking but there will be no bugs filed for Prefix support issues at this time. > > That above point withstanding, it is legal for EPREFIX to contain spaces, > > take care. > > repoman complained so I added the quotes last minute even if unnecessary > here and only tested in Paludis afterwards. They were not only unnecessary > but actually wrong. Usually stuff breaks in Paludis first. Bad luck. So, does this work: install-scripts = ${EPREFIX}/usr/$(get_libdir)/${PN}/bin When EPREFIX is "/path/to/location here/" ? IF not, I suggest you remove the EPREFIX var completely to avoid confusion that it was tested/supported. I'm not CC'd to this bug, if you would like more help please CC prefix@g.o or ask. I'll probably forget to check up.
(In reply to comment #6) > > So, does this work: > > install-scripts = ${EPREFIX}/usr/$(get_libdir)/${PN}/bin > > When EPREFIX is "/path/to/location here/" ? > Yes, will work as intended, whitespace is preserved. It's the same as with Java's properties files. > IF not, I suggest you remove the EPREFIX var completely to avoid confusion > that it was tested/supported. > > I'm not CC'd to this bug, if you would like more help please CC prefix@g.o > or ask. I'll probably forget to check up. I'm fine with the current solution, so unless you want something changed I see this as closed. Ie. the same as autotools based packages configure with ${EPREFIX} install to ${D}
(In reply to comment #5) > Thanks, well, there is this difference, one package manager passes it though > a shell, the other not. If you think Portages behavior is desirable then we > can close here. That setup.cfg file should be parsed by distutils rather than the package manager, so it shouldn't make a difference what package manager you use.
