> 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


*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

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

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

cd /usr/local/ports/gettext-1.05
patch -p0 < ../P_gettext-freebsd.patch
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


grep -i gettext /usr/ports/misc/help2man/Makefile
        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;
                        $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 <[EMAIL PROTECTED]>.

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
        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
        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

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.
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to