[Bug 1059154] New: perl-DBD-SQLite distributes sqlite3 sources
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1059154
Bug ID: 1059154
Summary: perl-DBD-SQLite distributes sqlite3 sources
Product: Fedora
Version: rawhide
Component: perl-DBD-SQLite
Assignee: jplesnik(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: jplesnik(a)redhat.com, mmaslano(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
steve(a)silug.org
DBD-SQLite sources come with sqlite3.c, sqlite3.h, and sqlite3ext.h which are
bundled SQLite sources. The files are not used when building perl-DBD-SQLite,
however they are installed into the system later into
/usr/lib64/perl5/vendor_perl/auto/share/dist/DBD-SQLite for this documented
purpose:
FOR DBD::SQLITE EXTENSION AUTHORS
Since 1.30_01, you can retrieve the bundled sqlite C source and/or header
like this:
use File::ShareDir 'dist_dir';
use File::Spec::Functions 'catfile';
# the whole sqlite3.h header
my $sqlite3_h = catfile(dist_dir('DBD-SQLite'), 'sqlite3.h');
[...]
You usually want to use this in your extension's "Makefile.PL", and you
may want to add DBD::SQLite to your extension's "CONFIGURE_REQUIRES" to
ensure your extension users use the same C source/header they use to build
DBD::SQLite itself (instead of the ones installed in their system).
First it does not match Fedora philosophy, second it installed different
sources from those used for building the Perl binding.
I propose to remove this feature completely.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=qxOHw1pDB0&a=cc_unsubscribe
9 years, 9 months
[Bug 1033018] New: syntax error in /etc/profile.d/perl-homedir.csh (perl-local-lib/perl-homedir)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1033018
Bug ID: 1033018
Summary: syntax error in /etc/profile.d/perl-homedir.csh
(perl-local-lib/perl-homedir)
Product: Fedora
Version: rawhide
Component: perl-local-lib
Severity: low
Priority: high
Assignee: iarnell(a)gmail.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: iarnell(a)gmail.com, jkachuck(a)redhat.com,
mmaslano(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
wgomerin(a)redhat.com
External Bug ID: CPAN 85667
+++ This bug was initially created as a clone of Bug #1032195 +++
Syntax error in /etc/profile.d/perl-homedir.csh
---Steps to Reproduce---
* Install perl-homedir
* Create a user with csh as login shell
* login with that user
The file /etc/profile.d/perl-homedir.csh, contained in perl-homedir,
contains a syntax error.
The command "eval `perl -Mlocal::lib`" fails with "Bad : modifier in $ (/).".
The processing of any login scripts stops at that error, resulting in an
incomplete environment for the user.
Fyi ...
.... looks like this is caused by missing {}:
ls3814:db2lin 8> perl -Mlocal::lib
setenv PERL_LOCAL_LIB_ROOT "$PERL_LOCAL_LIB_ROOT:/db2/db2lin/perl5";
setenv PERL_MB_OPT "--install_base /db2/db2lin/perl5";
setenv PERL_MM_OPT "INSTALL_BASE=/db2/db2lin/perl5";
setenv PERL5LIB "/db2/db2lin/perl5/lib/perl5:$PERL5LIB";
setenv PATH "/db2/db2lin/perl5/bin:$PATH";
ls3814:db2lin 9> setenv PERL_LOCAL_LIB_ROOT
"$PERL_LOCAL_LIB_ROOT:/db2/db2lin/perl5";
Bad : modifier in $ (/).
ls3814:db2lin 10> setenv PERL_LOCAL_LIB_ROOT
"${PERL_LOCAL_LIB_ROOT}:/db2/db2lin/perl5" ;
# no error
[...]
--- Additional comment from Petr Pisar on 2013-11-20 14:22:15 GMT ---
Thank your for this bug report and a suggestion how to fix. Unfortunately, this
is not enough.
If PERL_LOCAL_LIB_ROOT is not set, then tcsh will bail out with undefined
variable and the variable will not get set:
[test@rhel-7-0 ~]$ echo ${?PERL_LOCAL_LIB_ROOT}
0
[test@rhel-7-0 ~]$ setenv PERL_LOCAL_LIB_ROOT
"${PERL_LOCAL_LIB_ROOT}:/home/test/perl5" ;
PERL_LOCAL_LIB_ROOT: Undefined variable.
[test@rhel-7-0 ~]$ echo $?
1
[test@rhel-7-0 ~]$ echo ${?PERL_LOCAL_LIB_ROOT}
0
This is a know issue to the upstream
<https://rt.cpan.org/Public/Bug/Display.html?id=85667> with no ratified
solution yet.
--- Additional comment from Petr Pisar on 2013-11-21 10:50:37 GMT ---
Due to CSH limits on subcommand substitution and parsing if-then-else
statemens, appending to a variable FOO can be achieved this way:
test 1 == ${?FOO} && setenv FOO "a:${FOO}" || setenv FOO "a";
----
All Fedoras are affected.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=jn9WnmhloX&a=cc_unsubscribe
9 years, 10 months