[Pkg-utopia-maintainers] Bug#873596: avahi FTCBFS: needs to run host python

[Simon McVittie]

Control: severity -1 wishlist
Control: retitle -1 avahi FTCBFS: needs to run host python
Control: tags -1 - patch

On Wed, 20 Nov 2019 at 18:58:01 +0000, Simon McVittie wrote:
> On Tue, 29 Aug 2017 at 13:41:43 +0200, Helmut Grohne wrote:
> > --- avahi-0.6.32/debian/control	2017-01-23 09:41:58.000000000 +0100
> > +++ avahi-0.6.32/debian/control	2017-08-29 13:24:45.000000000 +0200
> > @@ -21,10 +21,11 @@
> >                 libexpat-dev,
> >                 libdaemon-dev (>= 0.11),
> >                 libdbus-1-dev (>= 0.60),
> > -               python-all-dev (>= 2.6.6-3~),
> > -               python-gdbm (>= 2.4.3),
> > -               python-dbus <!stage1>,
> > -               python-gtk2 (>= 2.8.6-2) <!stage1>,
> > +               python-all-dev:any (>= 2.6.6-3~),
> > +               libpython-all-dev (>= 2.6.6-3~),
> > +               python-gdbm:native (>= 2.4.3),
> > +               python-dbus:native <!stage1>,
> > +               python-gtk2:native (>= 2.8.6-2) <!stage1>,
> >                 libqt4-dev <!stage1>,
> >                 xmltoman,
> >                 intltool (>= 0.35.0)
> 
> This part hasn't been applied.

On closer inspection, I don't think (the modernized version of) this
change is necessarily correct.

I have changed this part to use python2 instead of python-all-dev.
avahi doesn't actually compile an extension or use Python development
headers - it just wants the interpreter. Normally, the obvious response
to this would be "then you should use python2:any, python-dbus:native
and so on".

However, python2 is run during the build to convert a text file listing
mDNS service types into a gdbm database. gdbm databases appear to be
endianness- and word-size-specific, so we need to build a database that
matches the host architecture's endianness and word size, even if they
differ from the build architecture's endianness and word size; so using
python2:any (or more generally, python2:${build-arch} when cross-compiling
on ${build-arch} for ${host-arch}) would not be correct.

I realize this makes it impossible to cross-compile avahi, which is
unfortunate - but I don't think that's fixable with the package's current
content.

Making it cross-compilable would require either a database format that
does not vary between architectures (which the upstream C code would need
to be taught to load), or a conversion step: for example, the package
could install service-type-database/service-types directly, and maintainer
scripts could "compile" it into each appropriate architecture's gdbm format.

To be honest this all seems massively overengineered for a table of just
over 100 service types, but that's an upstream design decision rather
than a packaging choice.

    smcv