FAQ
Hi all,

I like to use the aptitude provider to install packages -- all my
systems are Debian and it's consistent with what I use manually.
However, the aptitude provider seems to pass the '-y' option to
aptitude, which causes aptitude to simply assume yes for all prompts. I
understand that this might be necessary to avoid puppet hanging due to
the subprocess prompting, but in some cases aptitude can prompt because
of conflicts. In the case of conflicts, I would want puppet to just
return an error and let me handle the situation manually. Because
sometimes aptitude's first solution to a conflict is very suboptimal.

Does anyone know how I can configure this?

Cheers,
David

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Jcbollinger at Jul 23, 2012 at 1:28 pm

    On Sunday, July 22, 2012 5:58:01 PM UTC-5, David Banks wrote:
    Hi all,

    I like to use the aptitude provider to install packages -- all my
    systems are Debian and it's consistent with what I use manually.
    However, the aptitude provider seems to pass the '-y' option to
    aptitude, which causes aptitude to simply assume yes for all prompts. I
    understand that this might be necessary to avoid puppet hanging due to
    the subprocess prompting, but in some cases aptitude can prompt because
    of conflicts. In the case of conflicts, I would want puppet to just
    return an error and let me handle the situation manually. Because
    sometimes aptitude's first solution to a conflict is very suboptimal.

    Does anyone know how I can configure this?
    You would probably need to modify the code for the aptitude provider, or
    else to write an alternative package provider that has the behavior you
    want. Given that for the latter you could start from the built-in aptitude
    provider, those options are roughly comparable in difficulty.

    Before you consider that, however, I suggest you look at whether there is
    any combination of options that would elicit the desired behavior from
    aptitude. If there is, then the job would be fairly straightforward, but
    if not, then you're looking at rather a hard problem, both in interacting
    with the aptitude text UI and in interfacing that interaction with Puppet.


    John



    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/fVac8wwRgu4J.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jul 23, 2012 at 2:08 pm

    On Monday, July 23, 2012 8:28:20 AM UTC-5, jcbollinger wrote:
    Before you consider that, however, I suggest you look at whether there is
    any combination of options that would elicit the desired behavior from
    aptitude.
    And by that I mean to that aptitude should never prompt, but instead fail
    (returning a non-zero exit code) under those circumstances where you want
    it to do. Looking at the aptitude provider, you might be able to get
    around the exit code by parsing the standard error text, which is already
    done to cover one case.

    Also, I was a bit quick to deny the possibility of configuring your desired
    behavior: you cannot configure *Puppet* to change the behavior of the
    apitude provider, short of modifying the provider, but you may be able to
    configure *aptitude* to provide satisfactory default behavior. You could
    then use Puppet to ensure that the desired aptitude configuration is in
    place before you start managing packages.


    John


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/FbE2VGS1ThoJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • David Schmitt at Jul 23, 2012 at 2:47 pm

    On 23.07.2012 00:58, David Banks wrote:
    In the case of conflicts, I would want puppet to just
    return an error and let me handle the situation manually.
    Just say no to manual interventions.
    Because
    sometimes aptitude's first solution to a conflict is very suboptimal.

    Does anyone know how I can configure this?
    If you are experiencing conflicts in aptitutes package resolver, you're
    the victim of an underspecified manifest.

    You need to explicitely tell puppet to install AND remove the packages
    which are part of the resolution before installing the final package.

    If you instead solve it "manually", you'll loose the repeatability and
    stability of your installation.

    A very good example are apache MPMs. For some modules you need a
    specific one and relying only on package dependencies might lead to a
    flip-flop situation where installing A removes B and vice-versa. Having
    an explicit resolution in place will already fail when compiling the
    catalog, pointing you directly to the collision.


    Best Regards, David

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 22, '12 at 11:00p
activeJul 23, '12 at 2:47p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase