On Tue, Jan 25, 2011 at 4:36 PM, Micah Anderson <[email protected]> wrote:

>
> Hi all,
>
> It seems that an isolated group of us has come to a mini-consensus about
> #5604, but I wanted to post to the list to get some wider discussion.
>
> As detailed in #5604, the puppet apt provider mysteriously, and rather
> aggressively, disables apt-listchanges using an environment
> variable. This is a big ugly, and makes use of apt-listchanges
> impossible. It turns out that in an effort to fix #4418, which has to do
> with apt-listBUGS, apt-listCHANGES was also impacted. The bug was about
> apt-listBUGS, not apt-listCHANGES.
>
> in /usr/lib/ruby/1.8/puppet/provider/package/apt.rb there is this:
> <pre>
> ENV['APT_LISTCHANGES_FRONTEND'] = "none"
> </pre>
>
> Which is used by apt-listchanges in ./apt-listchanges/ALCConfig.py.
>
> According to git logs, this was changed in b0636354 (Dean Wilson
> 2010-08-13 13:50:52 +0100 19) with the commit msg: "Skip apt-listbugs
> and apt-listchanges when installing from puppet", but with no rationale.
>
> I think that if puppet wants to help people who have configured some
> software wrong (which is possible to do with apt-listchanges, you can
> configure it to use a pager interface, which will make puppet hang),
> then puppet should detect that and error/warn. It shouldn't just
> silently break the program completely.
>
> A hack around this would be to detect if the front-end of
> apt-listchanges is set to anything other than 'mail' or 'text' and then
> notify the admin that this wont work. Or just whitelist known
> non-interactive front-ends, so that things that should work do work.
>
> It seems to me that the bug fixed in #4418 was just too aggressive. It
> shouldn't have touched apt-listchanges, as the bug doesn't even mention
> that program... it should have only dealt with apt-listbugs. If someone
> *did* file a bug about apt-listchanges, the right solution probably
> would be to tell the person to configure their apt-listchanges properly,
> rather than try to be really clever (and obscure) in puppet, although
> whitelisting might be a proactive way of heading that off at the pass.
>
> Thoughts?
>
>
It sounds like what we really want to do is simply set
APT_LISTBUGS_FRONTEND="none"
right? That should achieve the original goal and remove this problem?



-- 
Nigel Kersten
Product, Puppet Labs
@nigelkersten

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

Reply via email to