#34 install woes

[Roger Luethi]

After installing from CVS, peep.conf was not installed
(despite of what INSTALL says), neither under /etc nor
under /usr/local/etc/.

peepd and sounds were (correctly) put under
/usr/local/, but peepd's looking for peep.conf in
/etc/peep/ (not /usr/loca/etc/...)
and complains if it's not there.

Copying peep.{conf,logtab,systab,themes} to /etc/peep/
fixed the
"Couldn't find peep configuration file" warnings.

The themes directory was searched for relative to the
cwd (not /etc/peep/):
23821 open("themes/collin.xml", O_RDONLY) = -1 ENOENT
(No such file or directory)

The sound path (/home/olsonco/peep/sounds/) and some other
details were apparently meant as examples and thus needed
changing, too.

If clients like peck do find a config file but are not
happy with it,
they throw rather unhelpful messages like:
-----------------------------------------------------------------
Cannot get information for the class [main]: No
information has been set. at
/usr/lib/perl5/site_perl/5.6.1/Net/Peep/Conf.pm line 281

Net::Peep::Conf::getClass('Net::Peep::Conf=HASH(0x84c3468)',
'main') called at
/usr/lib/perl5/site_perl/5.6.1/Net/Peep/Parser.pm line 224
Net::Peep::Parser::parseClient('Net::Peep::Parser=HASH(0x80fb084)',
'GLOB(0x8440670)', undef) called at
/usr/lib/perl5/site_perl/5.6.1/Net/Peep/Parser.pm line 70
Net::Peep::Parser::parseConfig('Net::Peep::Parser=HASH(0x80fb084)')
called at
/usr/lib/perl5/site_perl/5.6.1/Net/Peep/Parser.pm line 41

Net::Peep::Parser::load('Net::Peep::Parser=HASH(0x80fb084)',
'Net::Peep::Conf=HASH(0x84c3468)') called at
/usr/lib/perl5/site_perl/5.6.1/Net/Peep/Client.pm line 285
Net::Peep::Client::configure('Net::Peep::Client=HASH(0x80fb258)')
called at
/usr/lib/perl5/site_perl/5.6.1/Net/Peep/Peck.pm line 61

Net::Peep::Peck::peck('Net::Peep::Peck=HASH(0x80fb174)')
called at ./peck line 5
-----------------------------------------------------------------

IMO it would be nice to have a default setup that works
without
changes, with server and one or two clients (e.g.
logparser) on
localhost.

make test for the clients requires XML/Parser.pm and
File/MMagic.pm. Maybe it should test for that early on
instead of
hiding the error in a huge log.

[Michael Gilfix]

Logged In: YES
user_id=116038

Hiya. It appears SF no longer lets us know when new bugs are
reported. Strange. Sorry for the delay. I'm gonna have
Collin take a look at this. I think I directed him towards
some client issues as well. I agree that better error
reporting would be a big help.

As for an "out-of-the-box", we think we're a big step in
that direction. I suppose that the config files could have
paths that relate to the install paths of the sound and
config files.

As for the last issue, I believe that was resolved with some
very recent CVS. Please it give it another whirl and let me
know if otherwise. We're still working on assembling a
0.5.0, albeit slowly as we've both been bogged down with work.

Regards,

--Mike

[Collin Starkweather]

Logged In: YES
user_id=108103

The problem you mentioned about requiring XML::Parser etc.
is a problem endemic to Perl. When you install from the
CPAN, it automatically satisfies those dependencies. When
you install from source, you have to check the dependencies
yourself. Kinda like installing from RPM vs. apt-get.

In general, the Perl packaging system relies on the CPAN
module or the user to satisfy dependencies. That is, in
most CPAN packages, the author does not test for
dependencies or notify the user during the test phase that
they are not satisfied.

However, the latest 0.5.0 release candidate (which should be
released in the next few weeks) has a test script that will
look for these packages and provide some more informative
information to the user if they are not installed. Right
now it just comments on dependencies for the clients (e.g.,
File::Tail for logparser) that aren't satisfied, but I'll
include the core dependencies (e.g., XML::Parser) as well.

The note about working "out of the box" is spot on. We've
taken steps in that direction recently, with the client
using a sophisticated search path to find the proper
configuration file, but we could do more. I'll chat with
Michael about taking some more steps towards making sure it
works for most folks most of the time with the 0.5.0 release.

With regards to the first issue you mentioned, I think I
will wrap the configuration parsing in an exception handler
and make sure that any exceptions that are caught tell you
explicitly that there is a problem with the configuration
file and give you a line number. There are so many
configuration options that I can't see having a highly
descriptive message for each potential failure, but letting
the user know where in the configuration file the failure
occurred would be quite helpful.

Thanks for the feedback :-)