[debhelper-devel] Bug#878911: avahi FTBFS with debhelper 10.9.2

[Felipe Sateler]

On Sat, Oct 21, 2017 at 3:44 AM, Niels Thykier <niels at thykier.net> wrote:
> 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.

I think that in this case, the correct fix is to drop the Also= line.

1. We don't want to stop avahi-daemon socket if dnsconfd is removed
2. It appears the Also line is being treated as some form of
dependency manager (ie, to ensure that the avahi-daemon is started
when dnsconfd is started), but it is not necessary, because
avahi-daemon.socket is already Required.

So, I think we have not yet found a compelling case for dropping the
debhelper error. The Also line is not needed, and can be safely
dropped from the avahi-dnsconfd unit.

-- 

Saludos,
Felipe Sateler