Re: nut package freeze exception request (dependency based boot)
Hi all,
On Wednesday 17 September 2008 23:08:27 Anton Martchukov wrote:
> On 9/17/08, Petter Reinholdtsen <pere@hungry.com> wrote:
> > > If we need virtual package scripts in init.d than I see now to options:
> > >
> > > 1) Use a script instead of symlink with different lsb headers (this
> > > means rework of all packages using symlink)
> > I suspect this involves very few packages, and could be implemented
> > for Lenny, thought it is rather late for it. :) I would recommend this
> > approach.
>
> (Adding mantainers of all ups-monitor related packages to CC. Note,
> that upsd is orphaned, but it does not provide this link anyway).
>
> Can we work out a common solution for the problem? Now apcupsd,
> genpower, nut (in testing), powstatd create ups-monitor symlink in
> init.d since they provide ups-monitor virtual package. However,
> insserv cannot solve dependencies since it discovers several init
> scripts providing ups-monitor.
Do I understand correctly that in all of these packages providing the
/etc/init.d/ups-monitor symbolic link, that none of them attempt to register
/etc/init.d/ups-monitor with update-rc.d in their postinst scripts?
Is the link just there to be a "virtual/persistent" link to whatever service
which is installed and provides the functionality?
Inspection of the nut package leads me to believe this may be the case, so
I wrote a patch for insserv which ignores any symlink in /etc/init.d/ which
points to another script in /etc/init.d/, as I am not aware of any cases where
this is valid (nor should it be in the future if we intend to have discrete and
unique bundles of LSB data in the scripts).
Can anyone think of what is wrong with this solution?
>
> The solution for this might be to replace symlink with separte script
> (it can source original one) that have different lsb headers not to
> confuse insserv. Obviously at least the listed packages behavior
> should be changed to support this.
>
> Any objections?
Well, lets us try and adapt insserv first, if that fails we may change the
packages. For insserv to be widely accepted I think we must make effort to
make it an almost "drop in" replacement which do not need other package churn.
Thanks, Kel.
Reply to: