Package: bastille
Version: 1.3.0-2
Severity: important
On Tue, May 14, 2002 at 01:43:14AM -0400, Bob Bernstein wrote:
> This brave lad decided to connect his fairly up-to-date Debian "testing"
> branch machine to his cable modem tonight, and then took bastille 1.3.0-2 out
> for a test spin. The first complaint was that "Bastille/PSAD.pm" could not be
> found:
>
> "Executing PSAD Specific Configuration
> "Can't locate Bastille/PSAD.pm in @INC (@INC contains: /usr/lib
> /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5
> /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1
> /usr/local/lib/site_perl . /usr/lib/perl5/site_perl/ /usr/lib/Bastille) at
> /usr/sbin/BastilleBackEnd line 78."
>
> A brutish attempt at fixing this:
>
> cp /usr/share/perl5/psad.pm /usr/lib/Bastille/PSAD.pm
>
> brought movement, but only to new loggerheads:
>
> "Executing Logging Specific Configuration
> "syntax error at /usr/lib/Bastille/Logging.pm line 122, near ") {"
> "syntax error at /usr/lib/Bastille/Logging.pm line 138, near "}"
> "Compilation failed in require at /usr/sbin/BastilleBackEnd line 143."
>
> What's odd in the first glitch is that 'dpkg -L bastille' shows in part:
>
> /usr/share/Bastille/Psad.pm
>
> ...but this is an _empty directory_!
It does look like bastille's Perl modules are laid out very strangely.
For a start, if /usr/lib/Bastille is added to @INC and Bastille::API is
require()d, then /usr/lib/Bastille/Bastille/API.pm is needed, not
/usr/lib/Bastille/API.pm ...
Is there any reason why bastille can't just put its modules in the
normal place under /usr/share/perl5, as the Perl policy recommends? They
really don't look like they should be in /usr/lib anyway.
Thanks,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
