ports/115885: misc/help2man: help2man ignores installed gettext
snowcrash+freebsd
schneecrash+freebsd at gmail.com
Mon Sep 3 09:30:03 PDT 2007
arved at freebsd.org wrote:
> Synopsis: misc/help2man incorrectly insists on "p5-*" dependency when already installed as CPAN module
>
> State-Changed-From-To: open->closed
> State-Changed-By: arved
> State-Changed-When: Mon Sep 3 08:36:07 UTC 2007
> State-Changed-Why:
> It is unecessary to reopen another bug report, since you neither provide a patch nor convinced us that this should be a supported configuration.
again, WHAT "supported configuration" are you talking about here?
there's a properly installed perl-module. expecting freebsd ports of
perl programs to correctly use perl-compliant module installs is,
somehow, unreasonable?
here's what i know/see.
a freebsd port (help2man)
(a) looks for Locale::gettext
(b) finds Locale::gettext
(c) uses Locale::gettext in the build
THEN,
*fails* to recognize the in-place dependency IT ALREADY LOOKED FOR &
USED in updates of ports ...
> BTW. Don't miss the helpful answer by "Mel" on freebsd-question.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=116026
Mel wrote:
> Except for apps in the ports, because cpan/cpanp can not register *port* dependencies.
> RUN_DEPENDS does not mean "check if this file exists", it means "register a dependency on this port". What it does is:
> 1) check if the port is installed and if not install it.
> 2) add a line @pkgdep portname-version to $PKGDB/portname-version/+CONTENTS
> 3) add a line @DEPORIGIN:category/origin to $PKGDB/portname-version/+CONTENTS
> 4) add a line portname-version to $PKGDB/depname-version/+REQUIRED_BY
>
> If you wanna get rid of this problem, you could use an AFTER_INSTALL hack in >pkgtools.conf to undo 2)-4). Messy, but works.
> Much cleaner is to just use the ports system p5-*. It does it's job very well
that's not been my experience -- but, that's not the argument here.
i think it's not unreasonable to expect that "a perl-module is a
perl-module is a perl-module".
if it's properly installed -- and, in this case, it is, just like ALL
my other perl-modules, then a port should treate it
consistently/correctly.
just like all my other ports do -- just NOT help2man.
as for working around the problem ... the SIMPLEST solution is not to
bother with "ports" system in this case, and do a manual install of
help2man.
but my goal was to be helpful & report a problem.
> and since you're familiar with cpan/cpanp I'm sure you'll have no problem
> installing modules that might not exist in the freebsd ports into a directory
> *outside* the ports hierarchy (/usr/local) and add this to the module search
> path.
when help2man is installed via ports it *USES* the cpan-installed perl-module.
cpanp -u gettext Locale::gettext
module_info Locale::gettext
Can't create Module::Info object for module 'Locale::gettext' at
/usr/local/bin/module_info line 96.
cd /usr/local/ports
rm -rf gettext-*
wget http://search.cpan.org/CPAN/authors/id/P/PV/PVANDRY/gettext-1.05.tar.gz
tar zxvf gettext-1.05.tar.gz
# "#21625: Compilation under freebsd"
# http://rt.cpan.org/Public/Bug/Display.html?id=21625
http://rt.cpan.org/Ticket/Attachment/243467/103618/gettext-freebsd.patch
http://rt.cpan.org/Ticket/Attachment/243467/103621/gettext-MANIFEST
cd /usr/local/ports/gettext-1.05
patch -p0 < ../P_gettext-freebsd.patch
cp ../P_gettext-MANIFEST MANIFEST
perl Makefile.PL
make install
module_info Locale::gettext
Name: Locale::gettext
Version: 1.05
Directory: /usr/local/lib/perl5/site_perl/5.8.8/mach
File: /usr/local/lib/perl5/site_perl/5.8.8/mach/Locale/gettext.pm
Core module: no
now, building help2man
% portinstall help2man
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 176
packages found (-1 +0) (...) done]
[Gathering depends for misc/help2man .......... done]
---> Installing 'help2man-1.36.4_1' from a port (misc/help2man)
---> Building '/usr/ports/misc/help2man'
...
===> help2man-1.36.4_1 depends on file:
/usr/local/lib/perl5/site_perl/5.8.8/mach/Locale/gettext.pm - found
See? HERE it knows the dependency, AND finds it
NOT SURPRISING, as,
grep -i gettext /usr/ports/misc/help2man/Makefile
BUILD_DEPENDS=
${SITE_PERL}/${PERL_ARCH}/Locale/gettext.pm:${PORTSDIR}/devel/p5-Locale-gettext
RUN_DEPENDS=
${SITE_PERL}/${PERL_ARCH}/Locale/gettext.pm:${PORTSDIR}/devel/p5-Locale-gettext
USE_GETTEXT= yes
demonstrates that it, in fact, DOES look for a "normal" perl-module
**BEFORE** looking for the p5-Locale-gettext port-install!
...
===> Compressing manual pages for help2man-1.36.4_1
===> Registering installation for help2man-1.36.4_1
===> Cleaning for help2man-1.36.4_1
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 177
packages found (-0 +1) . done]
and the build continues to a cussessful conclusion.
pkg_info | grep help2man
help2man-1.36.4_1 Automatically generating simple manual pages from program o
pkg_info -rR help2man-1.36.4_1
Information for help2man-1.36.4_1:
Depends on:
Dependency: perl-threaded-5.8.8
Dependency: libiconv-1.9.2_2
Dependency: gettext-0.16.1_3
grep -i gettext `which help2man`
my $have_gettext;
require Locale::gettext;
Locale::gettext->import;
$have_gettext = 1;
unless ($have_gettext)
*gettext = sub { $_[0] };
sub _ { gettext @_ }
my $fmt = gettext shift;
die "$this_program: no locale support (Locale::gettext required)\n"
unless $locale eq 'C' or $have_gettext;
my $lsect = gettext $sect;
NOTE, the only dependency is to,
require Locale::gettext;
i.e., NOT something port-specific, but rather "just" a
properly-installed perl-module.
help2man, in fact, EXECUTES correctly as well, e.g.,
help2man -v
Option v requires an argument
`help2man' generates a man page out of `--help' and `--version' output.
Usage: help2man [OPTION]... EXECUTABLE
-n, --name=STRING description for the NAME paragraph
-s, --section=SECTION section number for manual page (1, 6, 8)
-m, --manual=TEXT name of manual (User Commands, ...)
-S, --source=TEXT source of program (FSF, Debian, ...)
-L, --locale=STRING select locale (default "C")
-i, --include=FILE include material from `FILE'
-I, --opt-include=FILE include material from `FILE' if it exists
-o, --output=FILE send output to `FILE'
-p, --info-page=TEXT name of Texinfo manual
-N, --no-info suppress pointer to Texinfo manual
--help print this help, then exit
--version print version number, then exit
EXECUTABLE should accept `--help' and `--version' options although
alternatives may be specified using:
-h, --help-option=STRING help option string
-v, --version-option=STRING version option string
Report bugs to <bug-help2man at gnu.org>.
so, to summarize:
I installed Locale::gettext via cpan.
Every other app/module/port/etc that usese it is "happy".
help2man installs/executes just fine with the cpan-installed Locale::gettext.
so everything on the build/install-side of the process is fine.
but, DESPITE this, on,
pkgdb --autofix --fix-lost
pkgdb -F
i get,
...
---> Checking the package registry database
Stale dependency: help2man-1.36.4_1 -> p5-gettext-1.05_1
(devel/p5-Locale-gettext):
Skipped. (running in non-interactive mode; specify -i to ask)
###########
## EXEC: pkgdb -F
---> Checking the package registry database
Stale dependency: help2man-1.36.4_1 -> p5-gettext-1.05_1
(devel/p5-Locale-gettext):
Install stale dependency? ([y]es/[n]o/[a]ll) [yes] no
New dependency? (? to help):
Delete this? ([y]es/[n]o/[a]ll) [yes] yes
Deleted.
#########
...
which reoccurs at each/every update.
I fail to see what's "correct" or "expected" about this. If help2man
port not only does not USE the p5-gettext-1.05_1 install in it's own
build, but, in fact LOOKS FOR and CORRECTLY USES the 'normal'
perl-module, how is it "expected behavior" that on updates, it
complains about stale dependency on p5-gettext-1.05_1?
if you all think this is CORRECT behavior, just let me know one last
time, and I'll leave you to "the way things are".
Anton Berezin wrote:
> Sorry, but I am afraid that if you insist on not using Perl modules
> installed via ports this means you cannot expect any ports depending on Perl
> modules to work.
are you impkying that a perl module installed by ports is somehow
different than one installed by perl/cpan itself?
i'd bet the perl folks might have an interesting opinion about that ...
> It might be fixable in this particular instance (did you provide a patch in
> your PR? thought so...), but you cannot expect it to work in general.
"thought so ...),"
nice. that's helpful.
More information about the freebsd-questions
mailing list