request for packaging

[Kilian Krause]

--=-SO4QeSCV9zey8hPN3Krt
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Diana,

Am Montag, den 27.12.2004, 21:08 +0200 schrieb Diana Cionoiu:
> Hello Kilian,
>=20
> 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=20
> has put some graffiti since it was Christmas, we haven't done so fast the=
=20
> roll back.
> YateGUI is another package and another story, the new version will be=20
> available until 15 january, so the one that we have dosen't worth the=20
> trouble. The new one we don't know if is working with Kaffe since is usin=
g=20
> 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?

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.

> The ldconfig problem has been solved in the cvs version (who will become=20
> very soon 0.8.6 - the last version from branch 0.8, we hope to have 0.9=20
> 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.

> On my sistem where i have installed zaptel from sources using "make=20
> install" the zaptel.h is in /usr/include/linux/zaptel.h . I don't know=20
> 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=3Dzaptel.h&searc=
hmode=3Dsearchfiles&case=3Dsensitive&version=3Dunstable&arch=3Di386
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.

> The reason for libyate.so to be in /usr/lib is because that is a more or=20
> less a generic library and it can be used in other projects, in fact we=20
> started a new project now that is using that library. The other reason is=
=20
> that /usr/lib is in the library path so if you wanna be able to start yat=
e=20
> you must have libyate in the library path (/var/lib/yate has no reason to=
=20
> be in the library path, the .yate files from there are loaded by=20
> libyate.so).

ok, thanks for the explanation. if they are needed by libyate.so, then
they're fine to reside within /usr/lib/yate.

> 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).

> I think i should clarify some things regarding yate. Yate mean Yet Anothe=
r=20
> Telephony Engine. Is made by a few parts.
>=20
> 1. The generic library - contain classes like String, Thread, Message and=
=20
> so on. (the header is telengine.h). We've made our own library to have th=
e=20
> Message base system.

ok, will become libyate and libyate-dev for the headers

> 2. The telephony library - contain classes like DataSource, DataConsumer=20
> 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.

> 3. The modules - each module is standalone (modules are communicating=20
> 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?

> 4. Libraries - in the contrib directory we have put some libs used by=20
> 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?

> 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.

> Yate is not asterisk, it runs like apache. You start yate with -d as a=20
> demon or you get the messages on the screen. To control yate or to do=20
> other things you can do a "telnet 127.0.0.1 5038" and try the help=20
> command. So normaly you should have a script like for apache (in mandrake=
=20
> is in /etc/init.d ) to start and stop yate.=20

ok, thanks for the hint. Still some "Yate loaded. Ready for
connections." would be helpful on the console. An init script will be
added. 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?

> 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.

--=20
Best regards,
 Kilian

--=-SO4QeSCV9zey8hPN3Krt
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD4DBQBB0GZ1vdkzt4X+wX8RAmM1AJ4s8EKSfO/wx4jNel9NFShLYJQFWQCYyuoQ
+MjZ+EUNco6M5DX74yOq2g==
=9KLI
-----END PGP SIGNATURE-----

--=-SO4QeSCV9zey8hPN3Krt--