Bugzilla Bug 13244

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 an attachment (id=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 an attachment (id=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 an attachment (id=26190) [details]
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.