Xindice is a native XML database develloped by the Apache Foundation. This ebuild installs xindice-1.0 and associated startup scripts. It is installed in /opt since there is no simple way to separate the conf/ lib/ bin/ and other dirs. If there is a better layout, i'll be happy to know about it.
Created attachment 6948 [details] The ebuild and scripts
WanKer: have fun
yeah, i have no idea ;)
"I have no idea" is approximately what I thought, too. I did some cosmetics to your ebuild (seems you misunderstood DEPEND and IUSE), but there are some things that make me sorrows: 1) does it really have to run as root? 2) how is access control done? 3) how can I test if it is working? The test commands from the documentation always just give me ERROR: Collection not found. Do you have some commands I could try to verify that it runs ok after modifications? As you maybe already guess, I don't have much clue of java and xml. So I am just perfect for helping with this :-) Waiting for your feedback, Patrick
First I must say I don't use xindice anymore :( I simply forgot the DEPEND field in the ebuild... my mistake. Xindice has an access control scheme in it IIRC. I did not try running it as another user. If you've got the error message ERROR: Collection not found. then the database work as you can connect to it. A query returning a result just after installation is: /opt/xindice/bin/xindiceadmin lc -c /db/system. The result should be: SysConfig SysUsers SysGroups SysSymbols SysAccess SysObjects Total collections: 6 Hope this helps!
Please try the version I've just put into CVS. It now runs as the user "xindice" who should be created during the installation. Cleaned up the startup script, aswell. Thanks for the ebuild, btw :-)
No complaints, so I assume it works.
Trying to get to FIXED state...
done.
Thanks for the ebuild but startup scripts are not working! As I can not reopen the bug, I think I should open a new bug for this (?)... It works when I change this line: start() { # start-stop-daemon --pidfile /var/run/xindice/xindice.pid\ # --start --background --user xindice --chuid xindice\ # --exec /opt/xindice/start to this line: start-stop-daemon -o --quiet --background --start --startas /opt/xindice/start \ --pidfile /var/run/xindice/xindice.pid --chuid xindice --user xindice Also at the /etc/env.d/21xindice script these lines should be added to make it work: PATH=/opt/xindice/bin ROOTPATH=/opt/xindice/bin CLASSPATH=/opt/xindice/java/lib/xindice.jar
reopening.
*** Bug 29653 has been marked as a duplicate of this bug. ***
1) So, you say it's not really started after the script says it was started? I tried the test from comment #5, and it seemed to work. How did you test? 2) What's the difference between your start command and mine, except that it does not check for absence of a non-existant process before running /opt/xindice/start? 3) About the environment changes: How can I test that these changes are necessary? It's not that I don't believe you, I just would like to see that it's sensible what I'm doing :-) 4) About the /opt issue - where do you see anything about "only for binaries" in http://www.pathname.com/fhs/2.2/fhs-3.12.html ? Talking about FHS, I just recognize that the current xindice package violates it in a few ways, for example should variable data rather be in /var/opt, then... If you see a way how this package can be broken up into other FHS-compliant locations instead of /opt, please tell me. Working ebuilds are also highly welcome :-)
Let me answer your questions. I will start with the last one: > "4) About the /opt issue - where do you see anything about "only for binaries" > in http://www.pathname.com/fhs/2.2/fhs-3.12.html ? > Talking about FHS, I just recognize that the current xindice package > violates it in a few ways, for example should variable data rather be > in /var/opt, then..." From the http://www.gentoo.org/doc/en/gentoo-howto.xml : "Note: The /opt directory is reserved in Gentoo Linux for binary-only packages. Examples include mozilla-bin, acroread, netscape and realplayer. Packages that get installed here will usually require a /etc/env.d/foo stub file. This is so that paths and additional variables can be included into the environment." I think this note makes it clear that non-binary packages are not prefered in the /opt directory. As to your FHS question, at the above doc it says that Gentoo closely follows FHS but not exactly. Look at this section: ----------------from the gentoo.org----------------------------- How to fit your packages into the filesystem ? Usually, if the package uses autoconf and automake, the default installation destinations are mostly correct, with a few exceptions: * If you're installing a program into /bin, /sbin, /usr/bin or /usr/sbin, then the program's corresponding man page should be installed into the /usr/share/man tree. This can often be accomplished by specifying a ./configure --mandir=/usr/share/man in the ebuild. * Documentation files are installed in /usr/share/doc, into a subdirectory reflecting the name, version and revision of the particular program. This applies to all programs: GNOME, KDE, X11 and console alike. However, some programs may install additional documentation and support files into a /usr/share hierarchy for their own purposes. * GNOME and KDE programs, should always be installed into /usr. In general, you should have ebuilds install their files into the /usr tree. Some programs can be compiled and linked with or without GNOME, KDE and X11 libraries, which can cause confusion. Our solution is to install everything into /usr which avoids ambiguity and needless complexity for ebuild authors. The location in which to install a program's files should not depend on the presence or abscence of specific USE variables. Therefore, the ebuilds in the portage tree almost always install into the /usr hierarchy exclusively. -----------------from the gentoo.org (above)------------------ The part above makes it clear about the locations. Do not try to follow the FHS , just use the default locations using the standard portage commands and all will be ok. Unfortunately I don't have the time to write an ebuild, I've already spent my worktime on this comment which is not smt my boss would appreciate ;) I'll try to comment on the other questions soon...
And now the 3rd question: > "3) About the environment changes: How can I test that these changes > are necessary? It's not that I don't believe you, I just would like > to see that it's sensible what I'm doing :-)" Don't believe anyone ;) . Seriously, env.d changes are necessary only if you are using the /opt directory for the installation. Because /opt is not included at the default path. Xindice has two commands 'xindiceadmin' and 'xindice' which is found (with your installation) at the /opt/xindice/bin directory. To use them without having to state the full path you must have that directory in the path. Portage scripts can automagically handle this if you state that in the /etc/env.d/21xindice file. 'env-update' script gets all the env. variables at the /etc/env.d/* files and merges them altogether then creates the /etc/profile.env file. Then /etc/profile script uses the profile.env to have the final variables. PATH=/opt/xindice/bin is necessary for this. Also when you login as the root, this will not work because profile scripts use ROOTPATH variable for the root account. So ROOTPATH=/opt/xindice/bin is also necessary. As with the CLASSPATH variable, it is absolutely necessary, if you don't want the users having to manually at the xindice.jar archive to the java classpath themselves. If this var. is not added, xindice will not run without adding it manually to the CLASSPATH. You should run 'env-update' if you manually change smt in the /etc/env.d/ dir. Portage runs it automatically after each emerge. HTH, best wishes...
Coming to your first 2 questions: > "1) So, you say it's not really started after the script says > it was started? I tried the test from comment #5, and it seemed > to work. How did you test? > 2) What's the difference between your start command and mine, except > that it does not check for absence of a non-existant process before > running /opt/xindice/start?" I didn't say that start script was wrong, just observed that behaviour. I was thinking that yours must also work but had not enough time to examine. Now, I have examined the error (without using --background) and it turns out to be that a permission problem. Running 'chown -R xindice.xindice /opt/xindice /var/run/xindice' solved the problem immediately. Your ebuild script does this already, looks like I had changed them to root.root while playing ;) So your start() and stop() scripts are correct and works. Thanks for this ebuild again.
About comment #14: Quite embarrassing for me, but as a lame excuse I can say that I am quite sure this part of the documentation changed after I checked it last time (which maybe was too long ago). About the passage "The part above makes it clear about the locations. Do not try to follow the FHS, just use the default locations using the standard portage commands and all will be ok." That's really funny because I went to /opt because I didn't yet figure out how to convice xindice to go into the proper directories (there is no configure step and I didn't yet dive into it deep enough to finde out where I can change the paths). About the CLASSPATH issue: The test from comment #5 worked without tweaking CLASSPATH. Can you show me some test commands that don't work without setting CLASSPATH? Looks like I'll have to waste a bit more time on this ebuild :-)
Ah, me again! Before commenting on yours, let me introduce one more bug (plz don't hate me :). It didn't compile with the latest sun-jdk, only with blacdown-jdk, and the older sun-jdks!! Here is the error: --------console output-------------- root # emerge -v xindice Calculating dependencies ...done! >>> emerge (1 of 1) dev-db/xindice-1.0 to / >>> md5 src_uri ;-) xml-xindice-1.0.tar.gz >>> Unpacking source... >>> Unpacking xml-xindice-1.0.tar.gz to /var/tmp/portage/xindice-1.0/work * Applying xindice-1.0.patch... [ ok ] >>> Source unpacked. dirname bin /opt/sun-jdk-1.4.2.01/jre/lib:/opt/sun-jdk-1.4.2.01/lib/tools.jar:/opt/sun-jdk-1.4.2.01/jre/lib/rt.jar:/opt/sun-jdk-1.4.2.01/jre/lib:/opt/sun-jdk-1.4.2.01/lib/tools.jar:/opt/sun-jdk-1.4.2.01/jre/lib/rt.jar:/opt/xindice/java/lib/xindice.jar:.:bin/../java/lib/xmldb.jar:bin/../java/lib/xmldb-xupdate.jar:bin/../java/lib/xmldb-sdk.jar:bin/../java/lib/xml-apis-1.0.jar:bin/../java/lib/xindice.jar:bin/../java/lib/xerces-1.4.3.jar:bin/../java/lib/xalan-2.0.1.jar:bin/../java/lib/openorb_tools-1.2.0.jar:bin/../java/lib/openorb-1.2.0.jar:bin/../java/lib/infozone-tools.jar:bin/../java/lib/examples.jar:bin/../java/lib/ant-1.4.1.jar:bin/../lib/*.jar:/opt/sun-jdk-1.4.2.01/lib/tools.jar Buildfile: build.xml init: [tstamp] ZoneInfo: /opt/sun-jdk-1.4.2.01/lib/zi/ZoneInfoMappings (No such file or directory) [tstamp] ZoneInfo: /opt/sun-jdk-1.4.2.01/lib/zi/ZoneInfoMappings (No such file or directory) idl: prepare: [mkdir] Created dir: /var/tmp/portage/xindice-1.0/work/xml-xindice-1.0/java/classes clean-jar: [delete] Deleting: /var/tmp/portage/xindice-1.0/work/xml-xindice-1.0/java/lib/xindice.jar src: [echo] Compiling Source [javac] Compiling 324 source files to /var/tmp/portage/xindice-1.0/work/xml-xindice-1.0/java/classes [javac] ZoneInfo: /opt/sun-jdk-1.4.2.01/lib/zi/ZoneInfoMappings (No such file or directory) [javac] /var/tmp/portage/xindice-1.0/work/xml-xindice-1.0/java/src/org/apache/xindice/core/query/XPathQueryResolver.java:502: array required, but org.apache.xpath.compiler.OpMapVector found [javac] int endFunc = pos + cmp.getOpMap()[pos+1] - 1; [javac] ^ [javac] /var/tmp/portage/xindice-1.0/work/xml-xindice-1.0/java/src/org/apache/xindice/core/query/XPathQueryResolver.java:502: operator - cannot be applied to java.lang.String,int [javac] int endFunc = pos + cmp.getOpMap()[pos+1] - 1; [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 2 errors BUILD FAILED /var/tmp/portage/xindice-1.0/work/xml-xindice-1.0/build.xml:123: Compile failed, messages should have been provided. --------------console output (above)----------------- Seems like a deprecation issue. Maybe should be compiled with -deprecation as it suggests. The versions for jdks that I've tested it are: sun-jdk-1.4.1.02 >> WORKS (with deprecation warnings) sun-jdk-1.4.2.01 >> FAILS blackdown-jdk-1.4.1 >> WORKS best wishes...
back to your comment, Don't be embarrassed, I had overlooked one important thing: xindice is not a C program! As xindice being a java program and not a GNU one, configuring it maybe difficult. Also the default portage scripts may or may not work with java programs. I don't have experience with ebuild-writing for java programs. Examining existing java ebuilds may help. I see ebuild commands like 'dojar' which can be helpful. Also 'ant' should be able to be configurable with parameters. Unfortunately, I am not an expert on this, so asking it to the forums can be much better. Good luck.
Also about the classpath issue, you are right, /opt/xindice/start script has this: --------------- JARS=`ls -1 $XINDICE_HOME/java/lib/*.jar` for jar in $JARS do CLASSPATH=$jar:$CLASSPATH ; done --------------- which effectively sets the CLASSPATH for the Xindice. I have overlooked that also, sorry...
Some good news and some bad news: I think I've found out how to bring xindice-1.0 into FHS conforming directories. The bad news: I can't compile xindice 1.0 or 1.1b1 with sun-jdk-1.4.2.01. Now I doubt if it makes any sense to roll out a new xindice ebuild if users with current java can't compile it anyway.
Patrick this is good news that you have found a way for FHS compliance. As for the Java issue, if you read my other comments, you see that xindice 1.0 can be compiled with the latest blackdown-jdk, but not with sun-jdk. So, maybe you can just put a dependency on specifically to blackdown?
I find it disappointing as they recommend Sun's 1.4.2 version: http://xml.apache.org/xindice/faq.html#faq-N10067 looking at the docs/README they do not recommend it for version 1.0 though. I checked the xalan versions and the fact is that the Sun JDK arranges to use its own version of Xalan instead of any other given on the command line (http://xml.apache.org/xalan-j/faq.html#faq-N100CB). Hope this helps!
Still have to meditate about this... ideas how to deal with this (drop xindice, try other sdk) are welcome.
Created attachment 26189 [details] xindice-1.0-r1 ebuild adds 'die' to the compile command to ensure that the packed is not merged if the compile fails. also adds epatch to compile properly on sun-jdk 1.4.
Created attachment 26190 [details, diff] xindice-1.0-r1 patch patches sun-jdk compile problem.
Thanks Benjamin... added with slight modifications (joined patches, removed the || die that epatch does anyway). Postponing the FHS stuff for a later version and closing this bug.
