Date: Mon, 3 Sep 2007 09:30:01 -0700 From: snowcrash+freebsd <schneecrash+freebsd@gmail.com> To: freebsd-questions@freebsd.org, fbsd.questions@rachie.is-a-geek.net, arved@freebsd.org Subject: Re: ports/115885: misc/help2man: help2man ignores installed gettext Message-ID: <70f41ba20709030930n4c02a4bexf948d64cf9da554c@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
arved@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70f41ba20709030930n4c02a4bexf948d64cf9da554c>