request for packaging

[Diana Cionoiu]

Hello Kilian,

> Hi Diana,
> 
> Am Montag, den 27.12.2004, 21:08 +0200 schrieb Diana Cionoiu:
> > Hello Kilian,
> > 
> > I will like to start by saying thank you for your work.
> > I'm sorry for the "Dokumentazione" part, our site is a wiki and someone 
> > has put some graffiti since it was Christmas, we haven't done so fast the 
> > roll back.
> > YateGUI is another package and another story, the new version will be 
> > available until 15 january, so the one that we have dosen't worth the 
> > trouble. The new one we don't know if is working with Kaffe since is using 
> > swing. I recomand to not do a package for it.
> 
> ok, sure. let's just stick with the yate and libyate package. Is the API
> to be included in some libyate-doc package? Which of the headers are to
> be in the libyate-dev for other programs to depend on? Is there a
> makefile install target for this or do we have to copy things over?

there is "make apidocs" to generate the api docs and is using kdoc (a 
small perl script). for docs i think the best option will be to put them 
generated into the yate package and install in a doc directory. there is 
no need for "yet another yate package".
 
> When packaging a library we should make sure the API is respected in the
> SONAME and SOVER and each API/ABI breakage is reflected as an
> incremented number of this SOVER. So far i don't see *ANY* version on
> the library file thus this needs to be addressed before i can package
> the lib outside the main yate package.

in the cvs we have solved that problem and libyate now have a SONAME, it 
dosen't have a SOVER since we don't need one (you are free to do a patch 
for debian for that). we consider that library should be in the same 
package as yate since yate can't even start without that library (the 
entire engine is there, the excutabile has something like 8k).

> > The ldconfig problem has been solved in the cvs version (who will become 
0> > very soon 0.8.6 - the last version from branch 0.8, we hope to have 
0.9 
> > branch in january).
> 
> Ok, good news.
> The very weird part is that while packaging i see:
> dh_shlibdeps -L yate -l debian/yate/usr/lib
> dpkg-shlibdeps: warning: format of libyate.so not recognized
> 
> I'm not sure if this is due to the lack of SOVER and SONAME compliance,
> but i guess this needs to be checked, identified and eventually fixed
> after the library is sanitized like pointed out above.

is due the lack of SONAME.

> > On my sistem where i have installed zaptel from sources using "make 
> > install" the zaptel.h is in /usr/include/linux/zaptel.h . I don't know 
> > debian packages but normaly it should be a zaptel-devel package.
> 
> there is no zaptel-dev which would include zaptel.h. Feel free to check
> on the webpage
> http://packages.debian.org/cgi-bin/search_contents.pl?word=zaptel.h&searchmode=searchfiles&case=sensitive&version=unstable&arch=i386
> for more variations of that filename. I suspect the zaptel doesn't allow
> distribution of a binary or development form, yet maybe this just needs
> to be raised against the package to have it fixed. For now it shouldn't
> hinder a first upload though the way i have made it work.

i think zaptel should not be a dependency.
in fact my opinion is that there should be a few packages.
1. yate - with libyate and most of the modules, and documenation
2. yate-h323 with the h323 module.
3. yate-qtclient - for the qt interface (see cvs for that).
4. yate-gtkclient - for the gtk interface.
5. yate-pgsql - for the 3 modules that need postgresql right now 
(cdrpgsql, pgsqlroute, register)

the package yate should not have as a dependency libpri or zaptel. of 
course i'm refering to the binary version, the most convinient way will be 
to link it static with libpri.a (this idea is copyrighted to Paul 
Chitescu).

> > The reason for libyate.so to be in /usr/lib is because that is a more or 
> > less a generic library and it can be used in other projects, in fact we 
> > started a new project now that is using that library. The other reason is 
> > that /usr/lib is in the library path so if you wanna be able to start yate 
> > you must have libyate in the library path (/var/lib/yate has no reason to 
> > be in the library path, the .yate files from there are loaded by 
> > libyate.so).
> 
> ok, thanks for the explanation. if they are needed by libyate.so, then
> they're fine to reside within /usr/lib/yate.

normaly the modules should be in /var/lib/yate/modules , mainly because 
will be much easier to be found. in the case of asterisk modules are in 
/usr/lib/asterisk/modules, but i don't like that aproach.

> > The test directory has some modules used to test the main yate engine.
> 
> please re-read my last mail. The test itself may have worked. There just
> was no success and no errormessage and running the testscript twice did
> result in 2 broken links. I'm sure that test is useful and meaningful
> for you, but to us, the question is whether it worked or not. And
> without a descriptive text this is impossible to tell (without reading
> the script and understanding it).

then feel free to write documentation, or do anything you like with those 
modules, anyway are just for developers to test the internal engine, not 
even the modules.

> > I think i should clarify some things regarding yate. Yate mean Yet Another 
> > Telephony Engine. Is made by a few parts.
> > 
> > 1. The generic library - contain classes like String, Thread, Message and 
> > so on. (the header is telengine.h). We've made our own library to have the 
> > Message base system.
> 
> ok, will become libyate and libyate-dev for the headers

i think those should be together in yate package, do not break things more 
then is necessary. yate is a very complicated system, let's make things 
as easy as possibile for users, most of the time the main package will do 
the job, there is not need to have 3 packages. i also think that the 
heders can be in the yate main package.

> > 2. The telephony library - contain classes like DataSource, DataConsumer 
> > and so on (used to pass telephony related data, the header is telephony.h)
> 
> hmm, if this is independant, this should become a libyate-tel or
> something. Else it'll be in libyate.

don't break them if is not necessary, in the futher you can modify them, 
but for the moment kept it simple.

> > 3. The modules - each module is standalone (modules are communicating 
> > between them by using messages with variabile parameters).
> 
> is it useful to split out a yate-h323, yate-iax, yate-sip for each
> module or just ship them all within the yate package?

no, is necessary just for the h323 module (openh323 is to huge), for the 
pgsql modules (since you don't know if people have pgsql-client libs), and 
gtk and qt (since a bunch of servers don't have an interface, and is 
stupid to link a server with some interface libs).
iax is in contrib directory, and the new sip (who will replace the exosip 
channel) will be here in about 2 weeks, so is not necessary to deal with 
exosip module.

> > 4. Libraries - in the contrib directory we have put some libs used by 
> > modules ( qt by qtclient, iax - for iax module, sip - for the sip module).
> 
> are they installed by default or do we need to take care of each of them
> separately?

are compiled by default and are linked statical with modules by default.

> > 5. The test suit - is in the test directory.
> 
> won't be included in the package, but would be nice to be run while the
> packaging stage.

not necessary.

> > Yate is not asterisk, it runs like apache. You start yate with -d as a 
> > demon or you get the messages on the screen. To control yate or to do 
> > other things you can do a "telnet 127.0.0.1 5038" and try the help 
> > command. So normaly you should have a script like for apache (in mandrake 
> > is in /etc/init.d ) to start and stop yate. 
> 
> ok, thanks for the hint. Still some "Yate loaded. Ready for
> connections." would be helpful on the console. An init script will be
> added. 

None of the daemons i know are doing that :), since are redirecting the 
output to a log file, we normaly use /var/log/yate.

> What's the default parameters we should launch it with? 

> Use a separate system user for yate? Have it launched on system boot? By
> default or only upon user affirmation?

use:

yate -dsv -l /var/log/yate .
-d is for daemon
-s is for supervisor (if yate dies god knows why supervisor will restart 
yate so we don't lose calls)
-v verbose 
-l log.

> > I also think that libyate should not be in a different package.
> 
> it will be the same source package, but a split out binary package the
> way you explained it.

please don't do that, keep the package in one piece.

Diana