[Pkg-utopia-maintainers] Bug#878911: avahi FTBFS with debhelper 10.9.2

[Niels Thykier]

Control: reassign -1 debhelper 10.9.2

Michael Biebl:
> On Tue, 17 Oct 2017 19:45:11 +0300 Adrian Bunk <bunk at debian.org> wrote:
>> Source: avahi
>> Version: 0.7-3
>> Severity: serious
>>
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/avahi.html
>>
>> ...
>>    dh_systemd_start
>> dh_systemd_start: Could not find "avahi-daemon.socket" in the /lib/systemd/system directory of avahi-dnsconfd. This could be a typo, or using Also= with a service file from another package. Please check carefully that this message is harmless.
>> dh_systemd_start: Cannot open(avahi-daemon.socket) for extracting the Also= line(s)
>> debian/rules:4: recipe for target 'binary' failed
>> make: *** [binary] Error 2
>>
>>
>> 19:35 < nthykier> bunk: Ideally, avahi would fix this on their end.  Without the fail-on-error, debhelper will silently "not do things" 
>>                   when the file is unreadable (even if only temporarily).  I.e. a "fail-to-fail"-case
>>
> 

Hi,

> avahi-daemon.socket is provided by avahi-daemon, a binary package which
> is built from the same source package and avahi-dnsconfd depends on
> avahi-daemon.

Ok, when I spoke with Adrian about this, I had a different understanding
of what happened and why it broke.

> Niels, can you be a bit more specific why this fails now and what you
> think is the proper fix?

I can explain why it fails; dh_systemd_start basically reads the Also=
line and pretends it was a part of the services listed on the cmdline/in
the package.  As it is now mandatory for us to be able to read the
service files, this will fail as the service is not where we expect to
find it.

The comment related to that part of the code reads:

"""
	# Handle all unit files specified via Also= explicitly.
	# This is not necessary for enabling, but for disabling, as we
	# cannot read the unit file when disabling (it was already
	# deleted).
"""

@biebl/@fsateler: when a unit has an Also= that points to a unit in a
different package can we then just ignore the relation?  I assume that
we should not disable/stop services from another package on removal.

Thanks,
~Niels