configure.ac improvements, part 2

[Fab]

The enable link-local messaging feature seems to be cool, but there's only one problem : I don't need it :-)

Consequences :

• I don't need avahi
• I need a --disable-zeroconf option for ./configure
• If zeroconf is disabled at ./configure time, the checkbox must always be disabled, even if avahi is installed 6 months later (see the following explanation)

Explanation : Suppose that I build Gajim without zeroconf support : avahi is not required. Six months later, I decide to install another software which require avahi.
If the checkbox auto-magically appear when avahi is installed, zeroconf support will be enable in Gajim, but for the package system of my distro (yes, I'm on Gentoo :p), Gajim will seems to be built without zeroconf support.

--> it make no sense.

I'll attach another patch. To apply it, you must :

• apply the patch of my precedent ticket #2751
• rename src/config.py to src/config.py.in
• apply it

This part of the patch :

		# ... and enabled with --enable-zeroconf configure option
		if @BUILD_ZEROCONF@:
			import os

will be switched to :

		# ... and enabled with --enable-zeroconf configure option
		if True:
			import os

or

		# ... and enabled with --enable-zeroconf configure option
		if False:
			import os

Tests are welcome. Thanks.

[Fab]

zeroconf.patch

[Fab]

Trac doesn't show the second part of the patch, probably because the src/config.py.in file doesn't exist. You must download it.

[asterix]

I don't see why we should force to disable an option that doesn't require a new compilation. If there is no option about that, this mean it is always included in Gajim, but is usable only if deps are installed

and it's the same for trayicon for ex: you have gnome-python-extra, but you built gajim with --disable-trayicon, you have trayicon ability because it's in GPE

[Fab]

Replying to asterix:

I don't see why we should force to disable an option that doesn't require a new compilation.

Simply because the user requested it by ./configure using --disable-zeroronf.

It's the role of ./configure to enable or disable implemented features, and to check the required dependencies, no ?

and it's the same for trayicon for ex: you have gnome-python-extra, but you built gajim with --disable-trayicon, you have trayicon ability because it's in GPE

Yes, it's true : disable should be respected : if enable, it should check for GPE, and if not present, it should build the module (another ticket ? :p)

Let us take another example : dbus.

Dbus is not strictly required, but you are forced to check it in configure, because if it used, you need dbus >= 0.60. What's happen if one day, you are forced to use avahi >= 0.8 ? You will be forced to check it's version in configure, except if the user doesn't want it : --disable-zeroconf.

I know that for the moment this is only assumptions, but am I wrong ?

Note that if zeroconf is enabled at configure time, it continues to work like now.

[patrys]

Why the hell does Gajim ebuild include an option to disable avahi in the first place? This is a runtime dependency, not build-time. THIS makes no sense.

[Fab]

Replying to patrys:

Why the hell does Gajim ebuild include an option to disable avahi in the first place?

It does not. Not avahi, but zeroconf support. avahi is a dependency, zeroconf is a feature. Do you see the difference ? If I don't need zeroconf support, I don't need avahi.

This is a runtime dependency, not build-time.

Whether it's a runtime or a build-time dep change nothing. We're not talking about a dependency, but about a feature which require a dependency. Since it's not a vital feature for gajim, I don't see why I can't definitively disable it.

If I ask the configure script of gajim to disable zeroconf, and I decide to install avahi the following day, that does not want to say that I want zeroconf support in Gajim. avahi is not only used by Gajim.

All that I ask it is that you are more strict with your (optional) dependencies : it's the role of configure script, else it is used for nothing.

[patrys]

So you are trying to tell me that you also need a flag to disable for example sound at BUILD time? Then I suggest you stop fixing your distro problems upstream. If people paid me for each package I had to patch to package it correctly in PLD Linux (and by packaging correctly I mean FHS compliance, not nonsense like disabling Avahi that just works), I'd be living next to Bill Gates by now. If you need it badly - use a downstream patch in your ebuild.

Again, I propose WONTFIX - this is a downstream, distro-specific (or user-specific) demand which makes no sense for the rest of the world.

[patrys]

In case you still don't get it - most distributions are BINARY, not SOURCE. We have separate run-time and build-time dependencies in apt and rpm. configure is for build-time deps. Forcing distro maintainers to recompile the package each time they want to flip the "use avahi" switch is pointless.

[Fab]

Replying to patrys:

So you are trying to tell me that you also need a flag to disable for example sound at BUILD time?

No. Why ?

Because sounds packages are not direct dependencies of Gajim.

Forcing distro maintainers to recompile the package each time they want to flip the "use avahi" switch is pointless.

If avahi is installed on the maintainers's system, it change absolutly nothing, since :

• --enable-zeroconf is the default
• gajim's behavior is not changed : if avahi is here, zeroconf is enabled, if not, it's disabled.

Look at the patch. Test it, with and without avahi.

[Fab]

I specify my last phrase : Test it, with and without avahi at BUILD time, and with and without avahi at RUN time.

[asterix]

I agree with patrys: zeroconf is an optional feature that just can't be disabled at build time, as sounds, trayicon, notification-window, ...

[Fab]

Ok, as you wish.

But I think it's wrong to :

• not check the dependencies at configure time, even if they are optional.
• not give the user the possibility to disable an optional feature.

Thanks.

[patrys]

1. Run-time deps don't belong in build scripts. I don't need nor want to have avahi running on the package building farm (we are not Gentoo and we don't compile packages on users' desktops).

2. There is a checkbox that does just that - it disables an optional feature.

[Fab]

Because I feel contempt in your answers, I will answer you for the last time, don't you notice that this ticket was closed ? Fell free to re-close it.

Replying to patrys:

1. Run-time deps don't belong in build scripts.

I'm not agree. configure.ac is not a build script. It's a configure script which produce a build script : the Makefile.

I don't need nor want to have avahi running on the package building farm

Run-time deps ARE deps, and you must check it in configure. In this case, explain me why you check about DBUS, which is a RUNTIME dep. Why do you check PYTHON, which is a RUNTIME dep ?

3.1 Writing configure.ac To produce a configure script for a software package, create a file called configure.ac that contains invocations of the Autoconf macros that test the system features your package needs or can use

http://www.gnu.org/software/autoconf/manual/html_node/Writing-configure_002eac.html#Writing-configure_002eac

we are not Gentoo and we don't compile packages on users' desktops

No, you are upstream, and I'm a simple user who tells you that your build system has a bug.
I'm the end-user who :

• wants to build Gajim on Debian, Fedora, LFS or FreeBSD
• doesn't know python
• doesn't want zeroconf support in gajim on this system
• need avahi.

[patrys]

Are you mad or what? Configure/make are run on the machine that BUILDS the package. That's NOT your desktop (in general). Makefile does NOT use Avahi. DBUS is checked only because Gajim need DBUS newer than 0.7 (it won't work with earlier versions as opposed to Avahi). Checking for Python is quite useful for distros that compile Python scripts and package the compiled files instead of the sources (performance reasons).

And yes, being a PLD Linux developer and a programmer myself I am quite capable of producing configure scripts.

[Fab]

Yes, I'm mad, if that can arrange you.

From the main page of gajim.org :

The goal of Gajim is to provide a full featured and easy to use Jabber client.

From Wikipedia :

Jabber is a collection of open, real-time communication technologies built on the Extensible Messaging and Presence Protocol (XMPP).

zeroconf support == avahi == bonjour protocol == call that as you want

From gaim's configure.ac :

AC_ARG_WITH(dynamic_prpls, [AC_HELP_STRING([--with-dynamic-prpls], [specify which protocols to build dynamically])]

...

AC_SUBST(DYNAMIC_PRPLS)
for i in $DYNAMIC_PRPLS ; do
 	case $i in
 		bonjour)	dynamic_bonjour=yes ;;
 		gg)			dynamic_gg=yes ;;
 		irc)		dynamic_irc=yes ;;
 		jabber)		dynamic_jabber=yes ;;

...

If I build gaim without bonjour protocol, and then I install avahi, it does not means that I want bonjour support in gaim.

All that I said is the following :

If zeroconf is an optional feature which require an optional dependency, I should have the possibility to definitively disable it at BUILD time. In this case, you must check for avahi in configure.ac, because YOU want this feature to be auto-enabled. It's not because you use an interpreted language you can make what you want. If everyone made like you, that would be the hell for all distros and users.

Ideally, the src/common/zeroconf dir should not be installed by make install if --disable-zeroconf is given to ./configure (that's the goal of ./configure !), and the checkbox should not appear in this case, and gajim should work normally.

Explain me where I am wrong, and why.

[nk]

guys, please relax. Fab what you say is cool in theory and I've seen it in actions (even in python scripts). But also means SVN has to use makefile vars etc, so it's impossible to run SVN, and we force to make install everything (after svn up happens). I don't like this.

zeroconf should be by default on, and if you like to disable it, you can use the preferences window (in case you run avahi and you don't like Gajim to use it). Most of the times though, it's true that if you run the daemon you want apps to use it [think of MS Windows Services/Unix Daemons]

if dir is not installed, then import zeroconf fails. Yann??

[Fab]

Replying to nk:

But also means SVN has to use makefile vars etc,

SVN is already using makefile && vars : it's written in the README :-)

You will need GNU autotools in order to install Gajim from svn.

Replying to nk:

so it's impossible to run SVN, and we force to make install everything (after svn up happens).

Why ? You do not touch the configure.ac and Makefile.am files everyday. For you, as developers, if you touch only *.py files, it change nothing : to test your commits, do you do a complete reinstallation of gajim each time ? SVN is running fine with this (no need make/make install) :

#!/bin/bash
SVN_DIR="$HOME/gajim_svn"
 
cd "$SVN_DIR"

svn co svn://svn.gajim.org/gajim/trunk gajim

"$SVN_DIR"/gajim/launch.sh -p svn

I'm sorry to get excited but, coming to me to say as arguments that configure/make must be run on machines that builds packages, and saying me that ./configure must not check dependencies, it's really to take me for an idiot. The only thing that would change, it's that maintainers must install avahi on their build farms to have exactly the same behavior as now, isn't their job ? How would they do if Gajim were written in C++ ? If you do not want to do it, ok, but don't say to me that it is because it's a runtime dep.

[asterix]

nk: we can use defs.py instead of the proposed solution, this way no need of config.py.in

but I don't see why we should add too many option at build time. One reason is that the packager could shoose not to include one or the other option, but you want it so you have to install gajim from sources. If there were no such option all should be ok. IMHO it's an advantage of python, no need to recompile to add an option.

and as nikos said, why installing avahi if you don't want to use it ? And if you don't want to use it, just don't check the link-local checkbutton in accoutns window. it's disabled by default

[anonymous]

Replying to Fab:

I'm sorry to get excited but, coming to me to say as arguments that configure/make must be run on machines that builds packages, and saying me that ./configure must not check dependencies, it's really to take me for an idiot.

You said that ;)

./configure is there to make sure the package builds. Packaginf phpMyAdmin does not require my machine to run neither Apache nor MySQL. That's what we call a run-time dependency. We list runtime dependencies in ebuilds, rpm spec files and debian sources. Not in packaging scripts. You don't seem to get the point. And disabling a feature that is disabled by default is beyond the scope of sanity unless you want to save extra 10kBytes of disk space by not packaging the zeroconf directory.

The only thing that would change, it's that maintainers must install avahi on their build farms to have exactly the same behavior as now, isn't their job ?

No, Fedora, PLD and ArchLinux? would rather patch the configure script not to check for Avahi as Makefile does not use it.

How would they do if Gajim were written in C++ ?

It's not. Optional run-time deps are one of the great features of Python.

If you do not want to do it, ok, but don't say to me that it is because it's a runtime dep.

That's the whole point. You want to permanently remove something that is optional and disabled by default anyway. Next week you will come and ask for --disable-emoticons as you don't like that selectbox to be active in your preferences and you will patch configure to not package the graphics. That's just hilarious. :D

[Fab]

Replying to anonymous:

You said that ;)
That's just hilarious. :D
We list runtime dependencies in ebuilds, rpm spec files and debian sources.

Are you a Gajim's dev ? Are you a Gentoo's dev ? You are brave to post as anonymous. Get out of my ticket. I'm not on gentoo's bugzilla.

Replying to anonymous:

Optional run-time deps are one of the great features of Python.

Yes ? And ? I can do it in C++ with exceptions if you want (optional run-time dep), but the problem is not here. End-user doesn't care that gajim is written in python.

You want to permanently remove something that is optional and disabled by default anyway.

No. I ask the possibility to permanently remove it.

Packaginf phpMyAdmin does not require my machine to run neither Apache nor MySQL.

dev-db/phpmyadmin
Description: Web-based administration for MySQL database in PHP

What will be happening if tomorrow, phpmyadmin starts to manage postgresql database in this way : upstream is starting to mix the code between MySQL and postgresql, but don't panic, the feature is optional, and at the end, in 10 years, you are obliged to install 400 files moreover for postgresql on a system which need only mysql support. Great.

Next week you will come and ask for --disable-emoticons as you don't like that selectbox to be active in your preferences and you will patch configure to not package the graphics.

Again, NO : there's no optional dependency for emoticons, and emoticons are not a serious thing like a protocol for an IM soft.

Replying to asterix:

but I don't see why we should add too many option at build time. One reason is that the packager could shoose not to include one or the other option

This is exactly the goal of SOURCE distros (here gentoo) : the end-user IS the packager. The maintainer of the ebuild wrote a bash script, and it's the user who decide which features he wants. The end-user doesn't care that Gajim is written in python, he doesn't care of the great features of python, he will just see that some features he-don't-want-but-which-are-optional will appear auto-magically if optional deps are installed later. It's completely incompatible with a system which build everything, and where you choose the features you want.

zeroconf is not XMPP, it's a great feature which need an option in configure.ac. If tomorrow you decide to create src/common/MSN, and use python bindings to a lib written in C++ which implement the MSN protocol, and you add a little checkbox below this one, you will continue to say that Gajim implement just XMPP ? And you will say that MSN is an option you cannot disabled like the sounds ?

On my system :

$ equery depends avahi
[ Searching for packages depending on avahi... ]
gnome-base/gnome-vfs-2.16.3
net-im/gajim-9999
net-im/gaim-2.0.0_beta5
net-im/ekiga-2.0.3
media-video/vlc-0.8.5-r5

Gajim is the only one that use avahi in this way.

EKIGA :


dnl #########################################################################
dnl   Check for Avahi mdns support
dnl #########################################################################
AC_ARG_ENABLE(avahi,
	[--disable-avahi	Disable Avahi support.],,)
if test "x${enable_avahi}" = "x"; then
  enable_avahi=yes
fi


VLC :


dnl
dnl  Bonjour services discovery
dnl
AC_ARG_ENABLE(bonjour,
  [  --enable-bonjour        Bonjour services discovery (default enabled)])
if test "${enable_bonjour}" != "no"
then
  PKG_CHECK_MODULES(BONJOUR, avahi-client >= 0.3,
    [PKG_CHECK_MODULES(BONJOUR, avahi-client >= 0.6,


GNOME-VFS :

dnl ****************************
dnl DNS-SD implementations
dnl ****************************
AM_CONDITIONAL(HAVE_AVAHI, false)
AM_CONDITIONAL(HAVE_HOWL, false)
			  
AC_ARG_ENABLE(avahi, [  --disable-avahi     build without avahi support])
msg_avahi=no
if test "x$enable_avahi" != "xno"; then
	PKG_CHECK_MODULES(AVAHI, avahi-glib >= 0.6 avahi-client >= 0.6,
		  	[AM_CONDITIONAL(HAVE_AVAHI, true)
		   	AC_DEFINE(HAVE_AVAHI, [], [Set if we can use avahi])]

However, if they really wanted, all this packages could try to load dynamically what they need, and see if the service is launched. They do not. They give the choice to the user at build time. Whether it's python, C or javascript, I don't care, the end-user don't care.

If tomorrow you decide to implement a game in gajim using pygame, and you just say that this lib is an optional dep, how explain the end-user that a game is appeared in Gajim when he has installed another game whereas the pygame useflag is not set on net-im/gajim ? I think it's a major problem. Patching gajim is the only way, except if theses optional runtime deps could be disabled at BUILD time, and you have all the tools to do it cleanly.

Anonymous, think what you want, I don't care. I think a package must be able to be built correctly before thinking at the building farm, and I think Gajim merit this. I'm just asking for the possibility to disable it, nothing more.

Someone has created a ticket a few days ago about a plugin's system for Gajim, that could be the solution : plugin == another ebuild which require avahi.

If the plugin is here, the checkbox is here. Then if avahi is here, the checkbox is enabled. For the other distros, it change nothing, just a plugin to install. And it would give more possibilities to Gajim, without modifying the core.

End, this time, really the end, do it or not do it, that's the question, but I think it's the logic.

[patrys]

Replying to Fab:

zeroconf is not XMPP, it's a great feature which need an option in configure.ac. If tomorrow you decide to create src/common/MSN, and use python bindings to a lib written in C++ which implement the MSN protocol, and you add a little checkbox below this one, you will continue to say that Gajim implement just XMPP ? And you will say that MSN is an option you cannot disabled like the sounds ?

In PLD we just display a banner at installation time telling the user that he might want to install additional packages, listing them along with the functionality they provide for Gajim.

If you really need such an option in Gentoo, just apply your patch downstream, as you said above, this is only related to Gentoo.

However, if they (Ekiga) really wanted, all this packages could try to load dynamically what they need, and see if the service is launched. They do not. They give the choice to the user at build time. Whether it's python, C or javascript, I don't care, the end-user don't care.

Not really, AFAIR, Ekiga needs Avahi headers at build time if you want it to support Zeroconf.

Someone has created a ticket a few days ago about a plugin's system for Gajim, that could be the solution : plugin == another ebuild which require avahi.

This might be a solution that would satisfy your needs but Zeroconf has to be tightly integrated with things like roster and requires special handling in some edge cases (also it does not offer the full feature support of XMPP for obvious reasons).

I'm not going to start a flame war here, please close this ticket if you feel that we got a consensus here.

[Fab]

closed.