[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#829649: lintian: Spurious error: init.d-script-missing-dependency-on-remote_fs



On Thu, Apr 20, 2017 at 11:12 AM, Niels Thykier <niels@thykier.net> wrote:
> Control: tags -1 moreinfo
>
> On Mon, 11 Jul 2016 21:05:25 -0300 Felipe Sateler <fsateler@debian.org>
> wrote:
>> On Mon, 04 Jul 2016 22:27:20 -0400 "Roberto C. Sanchez"
>> <roberto@connexer.com> wrote:
>> > Package: lintian
>> > Version: 2.5.45
>> > Severity: normal
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA512
>> >
>> > In preparing a new upstream release of the shorewall-init package, I
>> > found that lintian gave the following errors:
>> >
>> > E: shorewall-init: init.d-script-missing-dependency-on-remote_fs etc/init.d/shorewall-init: required-start
>> > E: shorewall-init: init.d-script-missing-dependency-on-remote_fs etc/init.d/shorewall-init: required-stop
>> >
>> > I checked with upstream was informed that shorewall-init doesn't work
>> > with NFS mount /usr and so assumes /usr is accessible without the need
>> > for $remote_fs in Required-Start and Required-Stop.  I inquired in
>> > #debian-devel on OFTC about this to see if it was OK to override.  I was
>> > told that this error is spurious as initramfs now mounts /usr and was
>> > suggested to file a bug report against lintian.
>> >
>>
>> Moreover, booting without /usr mounted is now officially[1]
>> unsupported, so there is no point in playing /-/usr whack-a-mole.
>>
>>
>> [1] #830829
>>
>> Saludos
>>
>>
>
> Hi,
>
> Should we remap this as a check for "$local_fs" or can people assume
> that /usr is always present?

I'd say yes. The idea is that it should be guaranteed that /usr is
mounted by the time the initramfs passes control to the init system.
This means that most software (except things that survive past the
init killing spree) can assume /usr is always available.

>  Currently, use of /var needs "$local_fs".

I'd say that use of /var requires $remote_fs. Remote-mounted /var is a
supported configuration.


-- 

Saludos,
Felipe Sateler


Reply to: