Re: nut package freeze exception request (dependency based boot) - Debian

This is a discussion on Re: nut package freeze exception request (dependency based boot) - Debian ; [Anton Martchukov] > I have checked for other packages, e.g. exim is providing virtual > package "mail-transport-agent", but I see no "mail-transport-agent" > symlink in /etc/init.d. Same for my "apache2" providing "httpd" > virtual package and again no symlink in ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Re: nut package freeze exception request (dependency based boot)

  1. Re: nut package freeze exception request (dependency based boot)

    [Anton Martchukov]
    > I have checked for other packages, e.g. exim is providing virtual
    > package "mail-transport-agent", but I see no "mail-transport-agent"
    > symlink in /etc/init.d. Same for my "apache2" providing "httpd"
    > virtual package and again no symlink in /etc/init.d.


    Yes, you have discovered bugs in the init.d script headers. These
    need to be fixed to avoid problems with dependency based boot
    sequencing.

    > I wonder if anybody provides virtual package symlink in /etc/init.d
    > and have already found solution for insserv? Looks like most
    > packages have no such symlink and thus no problems with insserv. Do
    > we really need it?


    I am not aware of any other package symlinking scripts the way
    ups-monitor does in /etc/init.d/.

    > 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.

    > 2) Changhe insserv to not count symlinks at all (do not know about
    > possible affects about it)


    This will break debian-edu (which symlink in a script used for the
    first boot after installation, and remove it after the boot). I am
    not sure about other effects.

    Happy hacking,
    --
    Petter Reinholdtsen


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: nut package freeze exception request (dependency based boot)

    On 9/17/08, Petter Reinholdtsen 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.

    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?

    --
    Anton Martchukov
    http://www.martchukov.com


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. 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 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.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: nut package freeze exception request (dependency based boot)

    [Anton Martchukov]
    > 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.


    Why is the symlink provided? Where is the definition of the
    ups-monitor virtual package written down? What is using this symlink?
    I assume a good solution should take into account the answers to these
    questions.

    So far I have only found the virtual package name defined, and no
    explanation about what packages providing this package name is
    expected to implement, nor how it is used. A quick grep in /etc/ for
    the name sent me to /etc/init.d/halt.

    Is it the only user? If so, perhaps the patch from Kel is the best
    way to fix it.

    Happy hacking,
    --
    Petter Reinholdtsen


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: nut package freeze exception request (dependency based boot)

    On Thu, Sep 18, 2008 at 11:19:15PM +1000, Kel Modderman wrote:
    > 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


    As for ups-monitor that yes, it's the case. As for symlinks
    I only heared about debian-edu earlier in this thread:

    > Petter Reinhold:
    >> 2) Changhe insserv to not count symlinks at all (do not know about
    >> possible affects about it)

    >This will break debian-edu (which symlink in a script used for the
    >first boot after installation, and remove it after the boot). I am
    >not sure about other effects.


    But I guess it's realted to ignoring symlinks at all.

    Can you fill a bug to push this patch to unstable?

    Thanks.

    --
    Anton Martchukov http://www.martchukov.com
    0xFC4FBF28 96BC 3DAB 231A 7FCC 4F49 D783 9A69 65C1 FC4F BF28

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjVEuIACgkQmmllwfxPvyhzaACfcWb5ih/kdaaAEVkVl2us0UwV
    Lz4AoJWDTD7VoUcHdjtexNHAOuZjBuNY
    =jJpr
    -----END PGP SIGNATURE-----


  6. Re: nut package freeze exception request (dependency based boot)

    On Thu, Sep 18, 2008 at 04:23:34PM +0200, Petter Reinholdtsen wrote:
    > Why is the symlink provided? Where is the definition of the
    > ups-monitor virtual package written down? What is using this symlink?
    > I assume a good solution should take into account the answers to these
    > questions.


    I am not a maintainer, but it looks like this is just to
    have a common name for any ups-monitor package. As you have
    found halt uses it to power off the ups without knowledge
    about which specififc ups daemon is installed.

    > Is it the only user? If so, perhaps the patch from Kel is the best
    > way to fix it.


    It should be ok, whenever we have one init.d linking to
    itself we have two scripts providing the same facility that
    is incorrect for insserv. If insserv will check such
    situation I do not see how it might be harmful.

    Another idea came to my mind, why can't we use alternatives
    for init.d scripts?


    --
    Anton Martchukov http://www.martchukov.com
    0xFC4FBF28 96BC 3DAB 231A 7FCC 4F49 D783 9A69 65C1 FC4F BF28

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjVFJsACgkQmmllwfxPvyj6fwCgqOw/w997Oic7RdjLpPX1IRfn
    UGwAn3+q5A4BEa8lcpFeV+Rdi9HpDh58
    =lqvW
    -----END PGP SIGNATURE-----


  7. Re: nut package freeze exception request (dependency based boot)

    On Sunday 21 September 2008 01:12:34 Anton Martchukov wrote:
    > On Thu, Sep 18, 2008 at 11:19:15PM +1000, Kel Modderman wrote:
    > > 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

    >
    > As for ups-monitor that yes, it's the case.


    I looked at a couple of the packages you identified and this was also the case.

    The nut package should reinstate the symlink then, and new insserv uploaded
    with modification to handle /etc/init.d/symlink -> script case.

    > As for symlinks
    > I only heared about debian-edu earlier in this thread:
    >
    > > Petter Reinhold:
    > >> 2) Changhe insserv to not count symlinks at all (do not know about
    > >> possible affects about it)

    > >This will break debian-edu (which symlink in a script used for the
    > >first boot after installation, and remove it after the boot). I am
    > >not sure about other effects.

    >
    > But I guess it's realted to ignoring symlinks at all.


    Yeah, the patch committed would ignore symlinks to a relative path which
    contain no path separator, which can only be scripts in the same dir that
    insserv is reading scripts from (/etc/init.d/).

    >
    > Can you fill a bug to push this patch to unstable?


    #485045

    Thanks, Kel.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: nut package freeze exception request (dependency based boot)

    On Sun, Sep 21, 2008 at 05:31:37AM +1000, Kel Modderman wrote:

    > I looked at a couple of the packages you identified and this was also thecase.
    > The nut package should reinstate the symlink then, and new insserv uploaded
    > with modification to handle /etc/init.d/symlink -> script case.


    Arnaud (the mantainer of nut) asked us to NMU because he is
    pretty busy at the moment. Who can do this? The nut package
    in testing still uses this symlink. Unfortunately I am not a
    DD.

    > > Can you fill a bug to push this patch to unstable?

    > #485045


    Thanks.

    --
    Anton Martchukov http://www.martchukov.com
    0xFC4FBF28 96BC 3DAB 231A 7FCC 4F49 D783 9A69 65C1 FC4F BF28

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjWAD4ACgkQmmllwfxPvygl4wCfSXWTyRdHpt sRlux6wrnhYVzc
    9hkAoJLPR6x4Z3Wv9oB2qWPDQdJFKadh
    =v39Y
    -----END PGP SIGNATURE-----


  9. Re: nut package freeze exception request (dependency based boot)

    > Why is the symlink provided? Where is the definition of the
    > ups-monitor virtual package written down? What is using this symlink?
    > I assume a good solution should take into account the answers to these
    > questions.


    It's there to be called by various parts of "init", though right now I
    think only /etc/init.d/halt calls it (to perform last-moment power-down
    of the UPS).

    There was a long thread on debian-devel about this feature. There was
    no way to place it under rc.d because it had be be executed absolutely
    last (after filesystems had been unmounted). Not all UPS systems
    provide a delay between the signal and power-off.

    -- Brian


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread