request for packaging

[Kilian Krause]

--=-bQaDuYMS+tRNoxexOk10
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Diana,

> > ok, sure. let's just stick with the yate and libyate package. Is the AP=
I
> > 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?
>=20
> there is "make apidocs" to generate the api docs and is using kdoc (a=20
> small perl script). for docs i think the best option will be to put them=20
> generated into the yate package and install in a doc directory. there is=20
> no need for "yet another yate package".

ok, let's not "have yet another yate package". agreed. Is the docs
shipping in the next release source, so we can just offer it as a
package that does "plain move files there"? I dislike an incremented
build-depends for the fact of generating a static documentation that can
be spread from the upstream distribution aswell. I.e. documentation
should only be rebuilt while packaging when it does include information
that's only present at compile time (which i don't see for an api).=20

Yet rolling the API docs alongside libyate-dev (in some libyate-doc)
would make sense IMHO. This also eases the fact of finding API docs for
the very version that you just installed rather than bothering upstream
which API the lib 3 or 4 releases ago had.
=20
> > When packaging a library we should make sure the API is respected in th=
e
> > 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.
>=20
> in the cvs we have solved that problem and libyate now have a SONAME, it=20
> dosen't have a SOVER since we don't need one (you are free to do a patch=20
> for debian for that). we consider that library should be in the same=20
> package as yate since yate can't even start without that library (the=20
> entire engine is there, the excutabile has something like 8k).

excellent. SONAME should be fine for now. ;)

> i think zaptel should not be a dependency.

build-dep or runtime dep?=20

> in fact my opinion is that there should be a few packages.
> 1. yate - with libyate and most of the modules, and documenation

"most of the modules" is a bit vague. Please do list specifically which
need to be shipped. Documentation of yate is hopefully not very much,
else having yate-doc would make sense.=20
Also we'll have libyate, libyate-dev and libyate-doc (for the API docs
if any). Maybe libyate-dbg too? Is a -dbg foreseen in the upstream
makefiles?

> 2. yate-h323 with the h323 module.

ok.

> 3. yate-qtclient - for the qt interface (see cvs for that).
> 4. yate-gtkclient - for the gtk interface.

both ok if they can be built from the same source.

> 5. yate-pgsql - for the 3 modules that need postgresql right now=20
> (cdrpgsql, pgsqlroute, register)

*sigh* ok. i guess we'll have to check why postgresql wasn't found. Is
there any light you can shed what's being searched for while configure
stage?

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

we'll see what we can do. Yet if we don't built against libpri or
zaptel, we won't have any dep on it either. So if this is split out
cleanly, then the binary deb won't have a dep on it even if we do build
with it. Yet from the above list, where is it supposed to go?

> > > 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 reaso=
n is=20
> > > that /usr/lib is in the library path so if you wanna be able to start=
 yate=20
> > > you must have libyate in the library path (/var/lib/yate has no reaso=
n to=20
> > > be in the library path, the .yate files from there are loaded by=20
> > > libyate.so).
> >=20
> > ok, thanks for the explanation. if they are needed by libyate.so, then
> > they're fine to reside within /usr/lib/yate.
>=20
> normaly the modules should be in /var/lib/yate/modules , mainly because=20
> will be much easier to be found. in the case of asterisk modules are in=20
> /usr/lib/asterisk/modules, but i don't like that aproach.

only if they are *var*iables. Thus i vote for /usr/lib/yate/modules too.
That does also resemble the pwlib/openh323/opal/asterisk approach for it
plain makes sense in the FHS. The /var/lib/yate is to be used for things
that might change. Which sounds unlikely except you plan to put audio
files etc. under there. If so, then we need both /usr/lib/yate/ for
libyate-components and /var/lib/yate/ for audiofiles, caches etc.

> > > The test directory has some modules used to test the main yate engine=
.
> >=20
> > please re-read my last mail. The test itself may have worked. There jus=
t
> > 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).
>=20
> then feel free to write documentation, or do anything you like with those=
=20
> modules, anyway are just for developers to test the internal engine, not=20
> even the modules.

that sounds like running it after compiling doesn't really help very
much in telling if the yate works ok. I guess we should go without then.

> > > I think i should clarify some things regarding yate. Yate mean Yet An=
other=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 hav=
e the=20
> > > Message base system.
> >=20
> > ok, will become libyate and libyate-dev for the headers
>=20
> i think those should be together in yate package, do not break things mor=
e=20
> then is necessary. yate is a very complicated system, let's make things=20
> as easy as possibile for users, most of the time the main package will do=
=20
> the job, there is not need to have 3 packages. i also think that the=20
> heders can be in the yate main package.

If the core library is shared and perused by more than one binary, then
it'd be quite a bad style to put them into the daemon package. For
example some admin might want to install the config UI on his
workstation without the daemon. Thus the lib needs to be split out.
Having headers in a non -devel package is also very broken packaging. If
headers shall be shipped, then within a libyate-dev package, not within
the daemon package. The "yate" package has the SOLE purpose of RUNNING
the daemon. Nothing more, nothing less. Every piece of developer file in
there needs to be removed and relocated into a -dev package where it
belongs.

> > > 2. The telephony library - contain classes like DataSource, DataConsu=
mer=20
> > > and so on (used to pass telephony related data, the header is telepho=
ny.h)
> >=20
> > hmm, if this is independant, this should become a libyate-tel or
> > something. Else it'll be in libyate.
>=20
> don't break them if is not necessary, in the futher you can modify them,=20
> but for the moment kept it simple.

ok, i gotta check the Debian policy if it's allowed to ship both libs in
one lib package, but as long as the SONAME matches, that might work.
It'd just become a major headache if the SONAME is different for each of
the two libs. And not splitting the lib out into a separate package
would hurt the Debian policy, so we might not wanna go that road either.

> > > 3. The modules - each module is standalone (modules are communicating=
=20
> > > between them by using messages with variabile parameters).
> >=20
> > 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?
>=20
> no, is necessary just for the h323 module (openh323 is to huge), for the=20
> pgsql modules (since you don't know if people have pgsql-client libs), an=
d=20
> gtk and qt (since a bunch of servers don't have an interface, and is=20
> stupid to link a server with some interface libs).
> iax is in contrib directory, and the new sip (who will replace the exosip=
=20
> channel) will be here in about 2 weeks, so is not necessary to deal with=20
> exosip module.

ok, we'll try to go with the list of modules some pages further up. Out
of interest, does your client speak SSL to the server? Or are you
sending login information in plain text thru the network?

> > > 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 mod=
ule).
> >=20
> > are they installed by default or do we need to take care of each of the=
m
> > separately?
>=20
> are compiled by default and are linked statical with modules by default.

ok

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

ok

> > > 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 mand=
rake=20
> > > is in /etc/init.d ) to start and stop yate.=20
> >=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.=20
>=20
> None of the daemons i know are doing that :), since are redirecting the=20
> output to a log file, we normaly use /var/log/yate.
>=20
> > What's the default parameters we should launch it with?=20
>=20
> > Use a separate system user for yate? Have it launched on system boot? B=
y
> > default or only upon user affirmation?
>=20
> use:
>=20
> yate -dsv -l /var/log/yate .
> -d is for daemon
> -s is for supervisor (if yate dies god knows why supervisor will restart=20
> yate so we don't lose calls)
> -v verbose=20
> -l log.

This all will work as unprivileged system user, right? Are you planning
on adding a swtich to choose the user id in the near future? Else, we'll
just provide a means to set this in the daemon config.

> > > I also think that libyate should not be in a different package.
> >=20
> > it will be the same source package, but a split out binary package the
> > way you explained it.
>=20
> please don't do that, keep the package in one piece.

we'll be piecing it together like your desire was above combined with
what the policy does force us to do. Yet don't worry about the lib being
split out. Debian isn't like other distros where more dependencies are a
bad thing to have.

--=20
Best regards,
 Kilian

--=-bQaDuYMS+tRNoxexOk10
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)

iD8DBQBB0JSVvdkzt4X+wX8RArKDAJ9XKpCnP9y0jOUgMKxkN4/8kINpMgCeP81u
U9qbsnnox/YyaX5y3sBAMSg=
=3hjQ
-----END PGP SIGNATURE-----

--=-bQaDuYMS+tRNoxexOk10--