[avahi] Modular Avahi releases?

[Sjoerd Simons]

Sorry for the late reply, been extremly busy with other things.. 

On Fri, Apr 07, 2006 at 03:08:49PM +0200, Lennart Poettering wrote:
> On Thu, 06.04.06 00:24, Sjoerd Simons (sjoerd at luon.net) wrote:
> 
> > Hi,
> > 
> > The avahi source tarball contains bindings for several languages.
> > Because of the way debian works, this cause various problems (or
> > well, overhead) for us.  Especially the mono bindings seem to cause
> > a lot of overhead (as mono itself still seems to be very much in
> > flux)
> 
> Could you explain this further? How does the current tarball make
> things complicated for you? 

 From this tarball we generate 24 different binary packages. Wich can be
 classified as core stuff (core/common libs and tools) , mono bindings, 
 glib bindings, qt bindings and some python utils. Which makes the package
 complex, but that's not a big problem (we can handle that).  
 
 The real problem with all of this lies more in the release management domain
 then in the purely technical domain. 
 
 If there is a small fix for just one part of avahi (say the qt bindings), 
 then a new package version needs to be made.  Which will be build on more then
 13 architectures and shipped to the mirrors. End-users will then get an update
 of all parts of avahi they have installed (even if they didn't have qt)..  So
 that's quite a waste of resources as most things didn't actually change.  We 
 cope with that by accumalating several small fixes before doing a new
 release, but it's always a trade-off. And because avahi is quite an important
 already, even small things can have big consequences.

 Furthermore debian has a concept of an unstable and a testing distribution.
 Which basically means that packages are tested for about 10 days in unstable 
 and if they don't have big problems they go on to testing.. Ofcourse things
 are somewhat more complicated then that. Packages can only move on if
 everything they need is in testing and all parts need to move at once.

 Now what does that have to do with avahi. Simple a lot of stuff depends on
 avahi these days, either directly or indirectly, such as the gnome desktop,
 the kde desktop and lots of others. So it's important to always get avahi into
 testing asap. 
 
 And this is exactly where the biggest problem lies: The current package
 depends on a lot of stuff, glib, qt, python, mono etc. A problem in any one of
 these will prevent avahi from going to testing. What recently happened was
 that mono had some issues, which blocked Gnome 2.14 and newer version of KDE
 going into testing.. In generally big interdependencies like this suck really
 hard in the unstable/testing model, as everything has to be just right for
 things like avahi to move on to testing.

> It's probably not that hard to build the  mono bindings only on 
> architectrues that support it?

That's what we're doing right now. Unfortunately where the mono bindings can be
build changes from time to time. For dbus we have nicer solution by building
the mono bindings just once, but we can't do that for avahi currently (But
that's another story and only helps for some things).. 

As said before, the bigger issue is that moving to testing is often hampered by
mono.

> > Would it be possible to split up avahi into several source release ?
> > So one for avahi's core, one for the mono bindings, one for qt
> > etc.. This would make our live as packages a lot easier. And for
> > upstream it'll become a lot easier to do small releases for small
> > fixes to a specific binding. Dbus is also going this route, which is
> > something i'm really looking forward too.
> 
> Hmm. I don't really see why this should make thing easier for
> us. Right in contrast, I would say it makes stuff harder for us, since
> we'd need to manage each micro package independently. That's much more
> maintainership work than we currently have. 
> 
> The qt bindinds just consist of 200 lines of code. Making a micro
> package of this, seems to me like a lot of overhead. Especially when
> it comes to autoconf, which will add a lot of extra space overhead for
> each micro package.

Well, i don't think it's a lot of extra space. Obviously you'll get some
overhead and redundancy in your autotools stuff. But i think most of that is
boiler-plate and some bindings specific stuff (which isn't duplicated). On the
other hand, you'll have a lot less things to check in each autoconf script, so 
the seperate autoconf scripts will probably be simpler.

I think the advantage for you as upstream is that it makes it easier to do
smaller release of just one bindings set more often. As your end users don't
have to download/build all of avahi just for a fix in one of the bindings for
example. But that ofcourse depends on how you do your release management.

> Something similar is true for the Glib, Python and Mono stuff. Those
> parts are really lightweight.

> Besides that, splitting Avahi up would certainly hamper our work to
> keep all bindings up-to-date. Simply because we wouldn't detect so
> quickly if we broke one of the bindings.

How do you currently check if one of the bindings broke ? Just by rebuilding
them against the new version (I don't really see a testsuite)? If that's the
case it shouldn't be that hard to rig something to build/test everything. 

Bindings are probably somewhat more demanding then ``normal'' applications, but
shouldn't be that different i guess. 
  
> Richt now I am not convinced at all that splitting up avahi would be
> an improvement. But maybe you can convince me of the contrary?

Well i can only tell you the issues we see as a distributor. Which aren't
necessarly upstream problems. More some things that will make things easier
for us :)
  
In general you guys seem to do things the right way, which is very very nice :)

I'm pondering to split out the mono stuff from the avahi dist into it's own
source package for debian in the future in case the upstream split won't
happen. Which will already fix the biggest issues for us (mono is really to
much in a flux to have something as crucial as avahi depend on it).

  Sjoerd
-- 
Down with categorical imperative!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/avahi/attachments/20060501/106d9f92/attachment-0001.pgp