Puppet users - Jan 2011 - RFC: erronously disabling apt-listchanges - #5604

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?

Micah
--

On Tue, Jan 25, 2011 at 16:36, Micah Anderson <micah@riseup.net> wrote:
> 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.
[...]
> 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.
So, that is actually surprisingly difficult to correctly detect and
fail over, which is probably part of why this ended up in the code.
For what that is worth.

[...]
> 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?
We generally try pretty hard to make things work, because nine out of
ten people who have puppet hang because of a bug in apt-listbugs or
apt-listchanges (which, historically, also had issues in the area
outside of puppet) are not going to file a bug report or anything.
They are just going to go the heck away.

That said, I am sympathetic with the idea that this is too
heavy-handed to apply everywhere. What would be super-useful is to
know how we can ensure that programs like that promise to be
non-interactive, without needing to cripple them.

I would actually go and hunt this up myself, because I use Debian and
puppet, but don''t have the bandwidth right now – if you can come back
with a concrete "this is what needs to be done" it shouldn''t
be that
hard to have the situation improved. :)

Regards,
    Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

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

On Tue, Jan 25, 2011 at 4:36 PM, Micah Anderson <micah@riseup.net> 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 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.