Ubuntu Packages

[vankooch]

Hi,

I'm building Yate debs for Ubuntu for a some time and now I want to setup a new PPA on lauchpad. As Yate has a lot of modules and it can be used for a wide range of usecases, I've split them in different groups/debs. The problem is that I just use some limited working scenario. To have a correct grouping I could need some help.

Current Debs:

• Yate: binary,shared,man
• libyate: lib file
• Yate-dev: yate-config, includes
• Yate-doc: docs
• Yate-client: Client files (gtk,..)
• Yate-scrips: sample scripts
• Yate-pgsql: Postgree Driver
• Yate-mysql: Mysql Driver
• Yate-openh323: OpenH323 Chan
• Yate-javascript: Javascript module
• Yate-gvoice: Google Voice module
• Yate-jabber: Jabber modules
• Yate-signaling: ysigchan, mgcpca, mgcpgw, ciscosm, sigtransport, lksctp, isupmangler 
• Yate-monitoring: cpuload, monitoring, ysnmp
• Yate-core: Rest of modules

This is only a starting point so if you have any ideas you are welcome!

Update:
You can finde the ppa under:
https://launchpad.net/~sico/+archive/yate

[Diana Cionoiu]

I don't see a reason why  Yate-javascript: Javascript module, Yate-gvoice: Google Voice module, Yate-jabber: Jabber modules will be apart from the yate core.

If you have too many packets than is hard for a user to figure out what is going on.

[asymetrixs]

I think it is good to split it up. As long as all core-packages are packed together so that yate can startup with minimal modules it is ok. So people can decide which modules they want to use and which they do not use. This is for example the same as apache is doing it. You can download apache and as module php support. So in my opinion it is the right way to do it, because it leaves it up to the user to install what he needs.

[Diana Cionoiu]

I disagree because in the case of apache and php, the php module of apache requires an installation of php, while the jabber module of Yate doesn't require something external, except ssl, which exists on every single system I know.
And javascript module doesn't even require ssl.

[asymetrixs]

Yate is developed in a modular way. It is up the the user to choose what he wants to compile and install and what he does not want to use. When the sources offer the flexibility of choosing which modules should be build, then also any package should provide this flexibility. Otherwise users could think that they do need to compile yate on their own if they only need specific modules and therefore they would not use the provided packages. Moreover if you have only one packages, one might wonder about its content. You could call it "yate with all modules" but "all" is not defined properly. It could mean that all modules of yate team are build in, but what about custom modules? Providing packages for each module also gives everyone else, who uses (self developed) modules, the opportunity of providing their module as package. Then - if they want to give it to the public - they only need to provide the module it as package, publish it and it should work. If all modules were in the same yate package, it would be impossible for someone to add a module to the package without contacting the package maintainer. And then it would be the work of the package maintainer to rebuild the package and to make it work "somehow", because people would expect it to work. So if it does not work when it is provided in a modular way,  the package provider - who published the module - can check what the error is and fix it. Then there is no need for the maintainer to deal with a problem of a module he does not know. Providing package modularity gives the author of a module the flexibility of providing the module package and only to maintain this package.

Yate is developed in a modular way. Compiling yate from sources give the user the flexibility of choosing the modules to compile and to use. Keep the modularity up, in any way.

[habibie]

I think it is good to split it up. As long as all core-packages are packed together so that yate can startup with minimal modules it is ok. So people can decide which modules they want to use and which they do not use. This is for example the same as apache is doing it. You can download apache and as module php support. So in my opinion it is the right way to do it, because it leaves it up to the user to install what he needs.

I completely agree with you on this. As a matter of fact, this is how developers from most, if not all, Linux (embedded) distros do it to port/package any (open source) software (i.e. YATE, FreeSWITCH, Kamailio, etc.). For instance, our YATE package on OpenWRT is packaged in this way using a software management utility called ipkg-utils (currently offline). In it, one will find how each YATE module gets packaged to satisfy its dependencies.

For OP (vankooch), perhaps looking at the OpenWRT's Makefile for YATE will shed some lights for you. Good luck.

[Diana Cionoiu]

This is how people endup with a half functional YateClient and a bunch of problems and prefer to use other operating systems.
It's silly to have a module for Jabber since Jabber Client has to be a part of YateClient and it's silly to ask me to install one more packet when that is a part of core Yate.

[vankooch]

For OP (vankooch), perhaps looking at the OpenWRT's Makefile for YATE will shed some lights for you. Good luck.

thx for the tip. On the first setup I've forked the deb packages build from the debian voip team, which are outdated. I've also watched the Make file on FreeBSD. I'll have look at the pkg for OpenWRT

I can understand diana, that she don't what to split it too many packages, because it could get wired for the user. On the other side I can understand asymtrixs and I think a normal installation would be >70 modules... which is also too much for avg. user.

How about splitting the packages a bit more in to scenarios, like server, client... Assuming a client installation is alway a GUI version, including jabber client modules, google voice client modules and vice versa for the server package.

• libyate: lib file
• Yate: binary,shared,man
• Yate-dev: yate-config, includes
• Yate-doc: docs
• Yate-core: Rest of modules
• Yate-client: Client files (gtk,..),  jabber, google voice client modules
• Yate-server: jabber,google server modules, monitoring, cpuload,ysnmp
• Yate-scrips: sample scripts, javascript module
• Yate-pgsql: Postgree Driver
• Yate-mysql: Mysql Driver
• Yate-openh323: OpenH323 Chan
• Yate-signaling: ysigchan, mgcpca, mgcpgw, ciscosm, sigtransport, lksctp, isupmangler

The contra is that we have modules packages and scenario packages. But we could merge yate-server and yate-server.
Btw I totally forgot the card drivers, like dahdi... never used them

For Information:

Update:

Mandriva Packages from Null Team:

Code: [Select]

%package alsa
%package gsm
%package speex
%package h323
%package isdn
%package lksctp
%package openssl
%package zlib
%package pgsql
%package mysql
%package client-common
%package qt4
%package scripts


Options on FreeBSD:

Code: [Select]

OPTIONS=MYSQL "MySQL Database support" off \
PGSQL "PostgreSQL Database support" off \
SCTP "Stream Control Transmission Protocol" on \
AMR_NB "AMR Narrow Band encoder (opencore)" off \
ILBC "Enable iLBC codec" off \
SPANDSP "Enable Spandsp faxing support" off \
DAHDI "Dahdi driver" off \
H323 "H323 software channel/protocol support" off \
SSL "Enable SSL support" off \
ALSA "Enable ALSA channel support" off

OpenWRT, if I get it right you can build every modules separately and install it as plugin.   

Code: [Select]

$(eval $(call BuildPackage,$(PKG_NAME)))
$(eval $(call BuildPackage,$(PKG_NAME)-collection-basic))
$(eval $(call BuildPackage,$(PKG_NAME)-scripts-php))
$(eval $(call BuildPackage,$(PKG_NAME)-scripts-perl))
$(eval $(call BuildPackage,$(PKG_NAME)-scripts-python))
$(eval $(call BuildPackage,$(PKG_NAME)-sounds))
$(eval $(call BuildPlugin,accfile,server,SIP or H.323 client (from file),))
$(eval $(call BuildPlugin,alsachan,client,ALSA Sound Channel,+alsa-lib))
$(eval $(call BuildPlugin,amrnbcodec,,AMR-NB Codec,@BROKEN)) # Missing amr-nb library
$(eval $(call BuildPlugin,analog,server,Analog (e.g. POTS) Channel,))
$(eval $(call BuildPlugin,analogdetect,server,Analog Data Detector,))
$(eval $(call BuildPlugin,analyzer,,Test Call Generator and AQ Analyzer,))
$(eval $(call BuildPlugin,callcounters,server,Count Active Call Legs,))
$(eval $(call BuildPlugin,callfork,,Call Forker,))
$(eval $(call BuildPlugin,callgen,,Call Generator,))
$(eval $(call BuildPlugin,ccongestion,server,Accept Status from Installed Engine Monitors,))
$(eval $(call BuildPlugin,cdrbuild,,Call Detail Record Builder,))
$(eval $(call BuildPlugin,cdrfile,,Call Detail Record to File,))
$(eval $(call BuildPlugin,ciscosm,server,SS7 Support,))
$(eval $(call BuildPlugin,clustering,server,Clustering Server Support,))
$(eval $(call BuildPlugin,conference,,Conference Room Mixer,))
$(eval $(call BuildPlugin,cpuload,server,Monitor CPU load and Inform Yate,))
$(eval $(call BuildPlugin,dbpbx,server,PBX IVR and Multi-routing from Database,))
$(eval $(call BuildPlugin,dbwave,server,Wav Media for DB Storage,+$(PKG_NAME)-mod-wavefile))
$(eval $(call BuildPlugin,dumbchan,,Dummy Channel,))
$(eval $(call BuildPlugin,enumroute,,ENUM Routing,))
$(eval $(call BuildPlugin,extmodule,,External Module Handler,))
$(eval $(call BuildPlugin,faxchan,,Spandsp Fax Channel,+libspandsp))
$(eval $(call BuildPlugin,filetransfer,,File Transfer Driver,))
$(eval $(call BuildPlugin,gsmcodec,,GSM Codec,+libgsm))
$(eval $(call BuildPlugin,h323chan,,Open H.323 Channel,+libopenh323 @BROKEN)) # libopenh323 doesn't create package or stagin_dir includes or libs
.....


[habibie]

I can understand diana, that she don't what to split it too many packages, because it could get wired for the user. On the other side I can understand asymtrixs and I think a normal installation would be >70 modules... which is also too much for avg. user.

Agree. For me, I compiled my own OpenWRT firmware to include only needed modules/packages into the firmware. This way, I will avoid any manual labor to install all the needed modules/packages.

How about splitting the packages a bit more in to scenarios, like server, client... Assuming a client installation is alway a GUI version, including jabber client modules, google voice client modules and vice versa for the server package.

If you take a closer look at the OpenWRT's Makefile for YATE, you will find a section of define Package/$(PKG_NAME) where it uses MENU:=1 option. I believe you can use this approach to selectively grouping the packages/modules.

[Diana Cionoiu]

We've tried to make the packets correct for Mandriva, and that can be found in the .spec file of the packaging directory of Yate.

[virrus]

I agree with Diana too. I think, there must be minimal possible number of packages.

Modules should separated into it's own package only if it requires some big fat dependency, like database or dahdi/zaptel.

Jabberclient is useful in server too (for example, my server sends me jabber message about who called me while i was away). It is only 118k and will not make yate-core much heavier. The same for gvoice.
Also, i see no reason for separating yate-core from libyate. I can't imagine scenario when libyate will be installed without yate-core.
Javascript may go inside some "yate-server" package with yate server binary itself together with monitoring and jabber server modules and may be with scripts.

So we will have 9 packages instead of 15...

[Diana Cionoiu]

This just came on the mail list:

"Can someone please confirm that the module register.yate is missing. I have installed yate on Ubuntu 12.04 using apt but the module register is missing and cdr storage on mysql is not possible. " by Sam Njenga.

Since there was a large number of e-mails like that I will really prefer Yate Ubuntu packets to be as less as possible.

[vankooch]

I agree with Diana too. I think, there must be minimal possible number of packages.

Modules should separated into it's own package only if it requires some big fat dependency, like database or dahdi/zaptel.

Jabberclient is useful in server too (for example, my server sends me jabber message about who called me while i was away). It is only 118k and will not make yate-core much heavier. The same for gvoice.
Also, i see no reason for separating yate-core from libyate. I can't imagine scenario when libyate will be installed without yate-core.
Javascript may go inside some "yate-server" package with yate server binary itself together with monitoring and jabber server modules and may be with scripts.

So we will have 9 packages instead of 15...

It's not about package size. It's more about a overload of modules for most use cases. It make not much sense to give a new user more than 60 modules to configure...
For exp. a new user installs yate client, why should he use (ysigchan, mgcpca, mgcpgw, ciscosm, sigtransport, lksctp, isupmangler, or rmanager, cpuload, javascript, pbx, dbwave and so on....)
And btw the dependency for mysql or pgsql are small.. libmysqlclient and libpq...there are more for zap/dahdi...
I agree with the lib pkg.. it make not much sense too use it alone, combining script and server make sense, tooo

How about:

• Yate-docs: doc files
• Yate-core: lib, yate binary, rest of modules (>50 modules)
• Yate-client: Client files, GTK
• Yate-server: server modules, monitoring, cpuload,ysnmp, scripting files, javascript, perl,php
• Yate-pgsql: Postgree Driver
• Yate-mysql: Mysql Driver
• Yate-openh323: OpenH323 Chan
• Yate-signaling: ysigchan, mgcpca, mgcpgw, ciscosm, sigtransport, lksctp, isupmangler

[Diana Cionoiu]

Hello,

I see no point in having yate server and yate signalling.
Also the client should have the ssl module and the jabber module.
I think the real question with be, what a user that has the package yate-server will do with that? Rather than, what it would not want.

Diana

P.S. Yate stoped to use GTK back in 2007 or so.

[virrus]

It's not about package size. It's more about a overload of modules for most use cases. It make not much sense to give a new user more than 60 modules to configure...

Most of them do not require any configuration. Sample configs are just fine.

For exp. a new user installs yate client, why should he use (ysigchan, mgcpca, mgcpgw, ciscosm, sigtransport, lksctp, isupmangler, or rmanager, cpuload, javascript, pbx, dbwave and so on....)

He shouldn't. He installs yate-client, which depends on yate-core (or how it will be called), qt4 and alsa.
If he really wants to use yateclient with PSTN or ISDN, he will install yate-signalling (anyway, it will require some non-trivial configuration).
The same for yate-h323. It should go into "Recommends" of "Suggests" control file field.

How about:

• Yate-docs: doc files
• Yate-core: lib, yate binary, rest of modules (>50 modules)
• Yate-client: Client files, GTK
• Yate-server: server modules, monitoring, cpuload,ysnmp, scripting files, javascript, perl,php
• Yate-pgsql: Postgree Driver
• Yate-mysql: Mysql Driver
• Yate-openh323: OpenH323 Chan
• Yate-signaling: ysigchan, mgcpca, mgcpgw, ciscosm, sigtransport, lksctp, isupmangler

IMHO, yate binary should go to the yate-server package.
The rest looks pretty well.

By the way, my "point of view" is implemented in my packaging info here:
https://github.com/vir/yate/blob/master/debian
It is far from perfect and some packages should definitely by renamed.
May be *-dbg should go into yate-dev, not sure.
I will be happy to see some critic and suggestions about it too