1. Reflecting jabber-base Some packages does not reflect jabber-base. For example the ebuild for jabberd-1.4 tries to install /etc/jabber as long as /var/log/jabber and something similiar. This should be done in jabber-base. Also the config-file name "multiple.xml" isn't really sensible. 2. Making jabber-base more sensible Jabber-base currently creates the user and the group "jabber". It creates /etc/jabber/, /var/run/jabber, /var/spool/jabber and /var/log/jabber. Also it sets the permission to jabber:jabber and 770. This is in generally ok. But it should go further: jabber-base could countain one generic init-script for jabber-daemons, which is generally needed because, otherwise it is not possible to install more jabber-servers than one. Now you could say "no one needs more than one jabber-server". That's generally true, but reflect that e.g. gg-transport and yahoo-transport (the rotten gaim-based C-implementation) need jabberd-1.4 as a dependency. So a generic jabber-server init-script would be the best solution to do so. it should be configured via /etc/conf.d/jabber-server in which you are able to select the jabber-server which should be started. 3. Removing USE-flags for transports In former times it was possible to provide USE-flags for transports. Today there are more than one implementation of transports. There is the Python-based family, PyAIM-t, PyMSN-t, PyICQ-t and - from other developers an xmpppy-based yahoo-transport and an IRC-transport (which are not working, when I tried them). On the other side there are the more traditional C-written ones, which are more or less broken. If we stay with the current USE-flag concept, it is not possible to use e.g. ejabberd with Py*-t-transports without editing the ebuild by yourself or doing things with packages.provided. So the solution is to remove all USE-flags from jabber-daemon ebuilds, which provides external transports. 4. Giving some love to jabber-issues As you can see, situation is not really good, so there is a lot of work to do. There must be a sensible concept how to deal with the given problems.
(In reply to comment #0) > 1. Reflecting jabber-base > Some packages does not reflect jabber-base. For example the ebuild for > jabberd-1.4 tries to install /etc/jabber as long as /var/log/jabber and > something similiar. This should be done in jabber-base. Also the config-file > name "multiple.xml" isn't really sensible. There is no problem with multiple ebuilds creating the same directories. And you are talking of the 1.4.3 versions, the ebuild for 1.4.4 that now has configure sport does not do that. The multiple.xml is a dep that comes from the old days. > > 2. Making jabber-base more sensible > Jabber-base currently creates the user and the group "jabber". It creates > /etc/jabber/, /var/run/jabber, /var/spool/jabber and /var/log/jabber. Also it > sets the permission to jabber:jabber and 770. This is in generally ok. But it > should go further: jabber-base could countain one generic init-script for > jabber-daemons, which is generally needed because, otherwise it is not possible > to install more jabber-servers than one. Now you could say "no one needs more > than one jabber-server". That's generally true, but reflect that e.g. > gg-transport and yahoo-transport (the rotten gaim-based C-implementation) need > jabberd-1.4 as a dependency. So a generic jabber-server init-script would be > the best solution to do so. it should be configured via > /etc/conf.d/jabber-server in which you are able to select the jabber-server > which should be started. > Why is not possible to install more jabber servers? Each transport comes with it's own init script and the several implementations of jabber servers have it's own init script. Having a init for all makes little sence to me, please explain. > 3. Removing USE-flags for transports > In former times it was possible to provide USE-flags for transports. Today > there are more than one implementation of transports. There is the Python-based > family, PyAIM-t, PyMSN-t, PyICQ-t and - from other developers an xmpppy-based > yahoo-transport and an IRC-transport (which are not working, when I tried > them). On the other side there are the more traditional C-written ones, which > are more or less broken. If we stay with the current USE-flag concept, it is > not possible to use e.g. ejabberd with Py*-t-transports without editing the > ebuild by yourself or doing things with packages.provided. So the solution is > to remove all USE-flags from jabber-daemon ebuilds, which provides external > transports. > This is a good idea, will remove the deps from jabberd > 4. Giving some love to jabber-issues > As you can see, situation is not really good, so there is a lot of work to do. > There must be a sensible concept how to deal with the given problems. > Love is being given, probably not the attention you would wish but work is being done.
(In reply to comment #1) [...] > Why is not possible to install more jabber servers? Each transport comes with > it's own init script and the several implementations of jabber servers have > it's own init script. Having a init for all makes little sence to me, please > explain. You have the problem that the init-script of a transport has the mark "need jabber-server", while jabber-servers are providing "provide jabber-server". So: if you install two jabber-server, you shoot in you leg, as runscript.sh puts errors. But you sometimes need jabberd-1.4 at least as a dependency for, let me say, jggtrans or yahoo-transport. As a Result I came to the idea that having an generic init-script would do the job. Think on generic function jabber_server_start(), jabber_server_reload() and jabber_server_stop(). This functions are provided by the different packages as there are ejabberd, jabberd-1.4 and jabberd-2.0. Also it would be possible, if it is intelligently implemented, that /etc/init.d/jabber-server starts more than one jabber-server. Take a look at the slottable MySQL-packages, something like this would work very well for jabber, don't you think so? [...] > This is a good idea, will remove the deps from jabberd When bumping ejabberd this should also be reflected. And I'm not sure, what's with jabberd-2.x Fine! Also virtuals would be possible but I think if you run a jabber-server you should know about transport and which transport you want and so on. [...] > Love is being given, probably not the attention you would wish but work is > being done. Is it a matter of time or a matter of fun?
*** Bug 140832 has been marked as a duplicate of this bug. ***
nelchael@nelchael jabber-base$ cat metadata.xml | grep email <email>chainsaw@gentoo.org</email> nelchael@nelchael jabber-base$ but this bug is assigned to Gustavo - who's maintaining jabber-base? And just for record: jabberd-1.4.4-r3 and jabberd-2.0.11-r1 make use of directories created by jabber-base. Also: in my opinion jabber-base should create user, group and required directories, nothing more - just like cronbase does. I'm for killing this bug.
Adding current maintainer of net-im/jabberd{,2}
This should be reported against the concrete package that is buggy on this
