8:01 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
People,
I'm having a few problems source compiling a number of perl modules. I
don't really like this vendor concept, whats wrong with site_perl??
But the problem I face is that the %files is inconsistent. For example,
in perl-HTML-Parser, the line is as follows:
%dir %{_libdir}/perl5/%(perl -MConfig -le 'print
"$Config{version}/$Config{archname}"')/HTML
but of course the files have been placed in vendor_perl/5.8.5. The
correct line in this case is:
%dir %(perl -MConfig -le 'print "$Config{vendorarch}"')/HTML
There are a number of other modules similarly broken. Comments please.
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFB2VAwCfroLk4EZpkRAvwbAKCTqyw6VfkfKIfTnYJOXRNjycUnswCfXi1c
AsQmAB0RKyvZTNBf2I+hGpA=
=Qw+6
-----END PGP SIGNATURE-----
noon
On Tue, 2005-01-04 at 01:01 +1100, Alan Milligan wrote:
I'm having a few problems source compiling a number of perl
modules. I
don't really like this vendor concept, whats wrong with site_perl??
The modules come from a vendor -> they should go into vendor install
dirs. Site install dirs are for local site installs so that admins can
override system installed stuff a la "perl -MCPAN -e install Foo-Bar"
and traditional tarball install. (Moving site_perl in /usr/local/...
would make this clearer FHS-wise.)
But the problem I face is that the %files is inconsistent. For
example,
in perl-HTML-Parser, the line is as follows:
%dir %{_libdir}/perl5/%(perl -MConfig -le 'print
"$Config{version}/$Config{archname}"')/HTML
but of course the files have been placed in vendor_perl/5.8.5. The
correct line in this case is:
%dir %(perl -MConfig -le 'print "$Config{vendorarch}"')/HTML
Better to just use %{perl_vendorarch} for arch dependent module packages
and %{perl_vendorlib} for arch independent ones. These are defined in
rpm 4.3-0.9 and later (~ FC2 and later) [0]. If support for older
systems is needed, these macros can be conditionally defined in
specfiles eg. like:
%{!?perl_vendorlib: %define perl_vendorlib %(eval "`%{__perl}
-V:installvendorlib`"; echo $installvendorlib)}
%{!?perl_vendorarch: %define perl_vendorarch %(eval "`%{__perl}
-V:installvendorarch`"; echo $installvendorarch)}
See also "grep %perl_ /usr/lib/rpm/macros".
And /usr/share/fedora/spectemplate-perl.spec if you have fedora-
rpmdevtools from fedora.us/pre-extras installed.
There are a number of other modules similarly broken. Comments
please.
In my experience, a lot of bug reports containing the magic string
"perl" in bugzilla.redhat.com or here do not tend to draw much
attention. Hopefully there will be something that the community can do
about it in future FC.
[0] https://bugzilla.redhat.com/114121
6:06 p.m.
Ville Skyttä <ville.skytta(a)iki.fi> writes:
On Tue, 2005-01-04 at 01:01 +1100, Alan Milligan wrote:
> I'm having a few problems source compiling a number of perl modules. I
> don't really like this vendor concept, whats wrong with site_perl??
The modules come from a vendor -> they should go into vendor install
dirs. Site install dirs are for local site installs so that admins can
override system installed stuff a la "perl -MCPAN -e install Foo-Bar"
and traditional tarball install. (Moving site_perl in /usr/local/...
would make this clearer FHS-wise.)
I like that idea. A lot. I'd not thought about it til now, but that
makes a tremendous amount of sense. It would also address the manpage
issue, I think. It would break backwards compatibility, though, with
older RPMs (unless we still looked in the /usr/lib/.../site_perl/
dirs, but I'm inclined not to).
In my experience, a lot of bug reports containing the magic string
"perl" in bugzilla.redhat.com or here do not tend to draw much
attention. Hopefully there will be something that the community can do
about it in future FC.
That's my fault. I don't get much time to spend on perl as I would
like. Now that CVS is exposed, though, I'm hoping I get more help
from the community :)
There are a TON of perl bugs at this point. Many are no longer valid,
but many are. I need to triage them all, but that would likely take
more time than fixing most of the ones worth fixing, I suspect.
Perhaps it would be better to start a general thread on perl and perl
module packaging, and go from there, see what people like/don't like,
etc.
btw perl 5.8.6 should be in rawhide tonight or tomorrow.
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.
7:52 p.m.
Once upon a time, Chip Turner <cturner(a)redhat.com> said:
Ville Skyttä <ville.skytta(a)iki.fi> writes:
> The modules come from a vendor -> they should go into vendor install
> dirs. Site install dirs are for local site installs so that admins can
> override system installed stuff a la "perl -MCPAN -e install Foo-Bar"
> and traditional tarball install. (Moving site_perl in /usr/local/...
> would make this clearer FHS-wise.)
I like that idea. A lot. I'd not thought about it til now, but that
makes a tremendous amount of sense. It would also address the manpage
issue, I think. It would break backwards compatibility, though, with
older RPMs (unless we still looked in the /usr/lib/.../site_perl/
dirs, but I'm inclined not to).
Hmm, you might as well change "vendor_perl" to "rpm_perl" then. I
don't
want RPM touching /usr/local (that's for the few odds and ends I install
manually and local or per-system scripts), but I install perl modules
from RPMs all the time. "vendor" to me means Red Hat or Fedora, so I
wouldn't make my perl module RPMs install into the "vendor" directory.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:16 a.m.
Chris Adams <cmadams(a)hiwaay.net> writes:
Once upon a time, Chip Turner <cturner(a)redhat.com> said:
> Ville Skyttä <ville.skytta(a)iki.fi> writes:
> > The modules come from a vendor -> they should go into vendor install
> > dirs. Site install dirs are for local site installs so that admins can
> > override system installed stuff a la "perl -MCPAN -e install Foo-Bar"
> > and traditional tarball install. (Moving site_perl in /usr/local/...
> > would make this clearer FHS-wise.)
>
> I like that idea. A lot. I'd not thought about it til now, but that
> makes a tremendous amount of sense. It would also address the manpage
> issue, I think. It would break backwards compatibility, though, with
> older RPMs (unless we still looked in the /usr/lib/.../site_perl/
> dirs, but I'm inclined not to).
Hmm, you might as well change "vendor_perl" to "rpm_perl" then. I
don't
want RPM touching /usr/local (that's for the few odds and ends I install
manually and local or per-system scripts), but I install perl modules
from RPMs all the time. "vendor" to me means Red Hat or Fedora, so I
wouldn't make my perl module RPMs install into the "vendor" directory.
Well, perl itself calls it vendor_perl. Various things like 'perl
-V:vendorlib' etc make me hesitant to diverge from upstream naming.
vendor_perl is where Fedora's perl modules end up landing; site_perl
is where your site's perl modules. RPM doesn't really have anything
to do with it. There's no law against rpm managing files living in
/usr/local, but that's one of the few places that is even viable for
things like man pages from third party apps that might conflict with
the ones living in /usr.
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.
9:56 a.m.
New subject: perl INSTALLDIRS=vendor (help and outdated perl modules)
Chip,
Ville Skyttä <ville.skytta(a)iki.fi> writes:
...
>On Tue, 2005-01-04 at 01:01 +1100, Alan Milligan wrote:
...
>In my experience, a lot of bug reports containing the magic
string
>"perl" in bugzilla.redhat.com or here do not tend to draw much
>attention. Hopefully there will be something that the community can do
>about it in future FC.
That's my fault. I don't get much time to spend on perl as I would
like. Now that CVS is exposed, though, I'm hoping I get more help
from the community :)
Count me in!
There are a TON of perl bugs at this point. Many are no longer
valid,
but many are. I need to triage them all, but that would likely take
more time than fixing most of the ones worth fixing, I suspect.
Here goes a list of outdated perl modules in Rawhide. A good place
to start is the perl Time::HiRes core module and the standalone one
(more information below). I can also help reviewing some of the bugzilla
perl entries, in particular the ones I created.
Outdated perl modules
Rawhide CPAN
----------------------------------------------------------------------
mod_perl-1.99_17-2.src.rpm mod_perl-2.0.0-RC3.tar.gz
(version 1.999020)
perl-Archive-Tar-1.08-3.src.rpm Archive-Tar-1.23.tar.gz
perl-Bit-Vector-6.3-3.src.rpm Bit-Vector-6.4.tar.gz
perl-BSD-Resource-1.23-6.src.rpm BSD-Resource-1.24.tar.gz
perl-Date-Calc-5.3-10.src.rpm Date-Calc-5.4.tar.gz
perl-DBD-Pg-1.31-6.src.rpm DBD-Pg-1.32.tar.gz
perl-DBI-1.40-5.src.rpm DBI-1.46.tar.gz
perl-Digest-SHA1-2.07-5.src.rpm Digest-SHA1-2.10.tar.gz
perl-File-MMagic-1.21-2.src.rpm File-MMagic-1.22.tar.gz
perl-Frontier-RPC-0.06-38.src.rpm Frontier-RPC-0.07b4.tar.gz
perl-HTML-Parser-3.35-7.src.rpm HTML-Parser-3.45.tar.gz
perl-HTML-Tagset-3.03-30.src.rpm HTML-Tagset-3.04.tar.gz
perl-LDAP-0.31-5.src.rpm perl-ldap-0.3202.tar.gz
perl-libwww-perl-5.79-6.src.rpm libwww-perl-5.803.tar.gz
perl-libxml-perl-0.07-30.src.rpm libxml-perl-0.08.tar.gz
perl-TermReadKey-2.20-17.src.rpm TermReadKey-2.21.tar.gz
perl-Text-Kakasi-1.05-12.src.rpm Text-Kakasi-2.04.tar.gz
perl-Time-HiRes-1.55-3.src.rpm Time-HiRes-1.66.tar.gz
perl-URI-1.30-4.src.rpm URI-1.35.tar.gz
perl-XML-Twig-3.13-6.src.rpm XML-Twig-3.15.tar.gz
Note: The core module Time::HiRes in perl 5.8.[456] is more
recent than the one packaged as a standalone module
(perl-Time-HiRes 1.55).
perl Time::HiRes
-----------------------
5.008003 1.52
5.008004 1.59
5.008005 1.59
5.008006 1.65
Bugzilla (perl component)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136496
Bugzilla (perl-Time-HiRes)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136494
Note2: Archive::Tar now requires IO::Zlib which is already
available in Fedora.us/extras repositories
Bugzilla (perl-Archive-Tar component)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136498
Perl SRPMS that include .tar.bz2 files
----------------------------------------------------------------------
QA packagers can't validate these tarballs (CPAN only has .tar.gz files
and some .zip files):
WARN: perl-libxml-perl-0.07-30.src.rpm has a BZ2 source file!
WARN: perl-XML-Encoding-1.01-26.src.rpm has a BZ2 source file!
WARN: perl-XML-Grove-0.46alpha-27.src.rpm has a BZ2 source file!
Best regards,
jpo
--
José Pedro Oliveira
* mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/~jpo *
* gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
7043
days inactive
7059
days old
5 comments
5 participants
participants (5)
-
Alan Milligan -
Chip Turner -
Chris Adams -
Jose Pedro Oliveira -
Ville Skyttä