Bug#667902: RFS: downtimed/0.5-2
Dear Arno,
söndag den 8 april 2012 klockan 14:59 skrev Arno Töll detta:
>
> * You use dpkg-buildflags but you didn't declare a versioned
> build-dependency against dpkg-dev which explicitly supports "--export
> *FLAGS" (1.16.1 I think). My rule of thumb is to declare
> build-dependencies against build-essential packages if you use features
> not satisfied in stable. Otherwise you break backports and such without
> notice.
You are correct in my omission of a build dependency in dpkg-dev (>= 1.15.7),
but you are incorrect in the mechanisms invoked. I have used the explicit
make directive "export" in order to support "stable/squeeze". I have not
used the switch "--export" from "dpkg-buildflags". Thus version 1.15.7
is the correct level.
> * Please document why you are overriding
> init.d-script-possible-missing-stop. For the other Lintian tag you
> override I can see your point, but I personally wouldn't bother since
> you require $remote_fs in start anyway. If you want, that's fair enough.
>
> * Not sure about your rationale to override dh_installinit either. The
> whole point of LSB headers is to determine the dependencies out of them.
Both these are connected. Investigating this further, I observe incomplete
behaviour of "update-rc.d" caused by "insserv". The serious problem is that
I am not able to reactivate the service after a sejour into runlevel 1.
A rebuilt package with
Default-Start: S 2 3 4 5
Default-Stop: 0 1 6
is never restarted after
# init 1
# exit
and in addition "insserv" is never admitting the new starting links
in "/etc/rc{2,3,4,5}.d/S??downtimed". Ideas to resolve this? This
must be result in order to update the package properly, and to allow
"downtimed" to resume service after the administrator has temporarily
entered single-user mode. Had he gone into singel-user mode already
at boot time, then the mechanisms are already in place, but not from
within a running system. There is still an override needed to get "S"
as a runlevel for starting "downtimed". I want to keep this in order
to have the service detect a booted system at the earliest possible
time.
Best regards,
Mats E A
Reply to: