Hubert Feyrer wrote:

> On Mon, 20 Dec 1999, Simon Burge wrote:
> > 	@comment $NetBSD$
> > 	lib/perl5/${MACHINE_ARCH}-${LOWER_OPSYS}/5.00404/perllocal.pod
> > 	lib/perl5/man/man3/Date::Calc.3
> > 	lib/perl5/site_perl/${MACHINE_ARCH}-${LOWER_OPSYS}/auto/Date/Calc/.packlist
> > 	lib/perl5/site_perl/${MACHINE_ARCH}-${LOWER_OPSYS}/auto/Date/Calc/Calc.bs
> > 	lib/perl5/site_perl/${MACHINE_ARCH}-${LOWER_OPSYS}/auto/Date/Calc/Calc.so
> > 	lib/perl5/site_perl/Date/Calc.pm
> > 	@dirrm lib/perl5/site_perl/${MACHINE_ARCH}-${LOWER_OPSYS}/auto/Date/Calc
> > 	@unexec rmdir %D/lib/perl5/site_perl/${MACHINE_ARCH}-${LOWER_OPSYS}/auto/Date 2>/dev/null || true
> > 
> >  Q1) The first file (perllocal.pod) also exists in the net/p5-Net-DNS
> >      package, and thus will conflict.  No other perl5 package seems to
> >      add this file.  Any advice?
> 
> Move this out of this and the net/p5-Net-DNS package, and add a
> @unexec rm .../perllocal.pod 
> line to the perl package. That way, whatever random package notes it's
> existance there, it will be removed once perl is wiped out.
> Perl should do this more sane, but we're not here to save the world.

Done (everything 'cept the "save the world" bit :-).

> >  Q2) The "@unexec rmdir" will try to remove the .../Date directory,
> >      which will fail if the directory is not empty (if another p5-Date-*
> >      package is still installed).  Hence the use of "@unexec rmdir"
> >      instead of just "@dirrm".  It seems a few perl packages try to
> >      clean up any intermediate directories, but not many.  Should we
> >      have a "@dirrm-f" or something similar that doesn't fail with the
> >      "unable to completely remove directory" error?
> 
> The correct approach here is to move this out of the various packages, and
> let the base package (perl) create and remove such directories.
> Unfortunately, have no way to denote an empty dir in a PLIST right now, so
> you'll have to either use a @exec mkdir/@dirrm combination, or use a
> .keepme-file (and a @dirrm).

Part of the problem is that I don't think we'd know what all the perl
`categories' are in advance, so this list could be ever changing.
Perhaps best for now would be:

	@unexec rm -r %D/lib/perl5/site_perl/${MACHINE_ARCH}-${LOWER_OPSYS}/auto

somewhere in lang/perl5's PLIST-mi.

> >  Q3) I'm using:
> > 	DISTNAME=	Date-Calc-4.2
> > 	PKGNAME=	p5-${DISTNAME}
> >      in the Makefile, after pkglint complained about something based on
> > 	PKGNAME=	p5-TimeDate-1.08
> > 	DISTNAME!=	echo ${PKGNAME} | sed -e 's/^p5-//'
> >      Is the first the preferred form?
> 
> Definitely!

Cool - there's about a dozen other p5 packages that use the "ugly"
construct.  Shall I change those?  The www/p5-libwww case it a bit
ugly though, and looks like it will need some sed'ing either way...

> Something else:
> Perl does not support shared objects etc. on all our archs, and thus the
> .so and .bs file will not be there. Example archs are (I think) pmax and
> alpha (don't ask that's perl...). See e.g. security/p5-MD5 for a
> workaround using different PLISTs. 

Yuck!  I'll do this for my package for now.

Hmm, both pmax and alpha are ok - maybe it might be time to deprecate
non shared support.  I wonder about pc532, vax, perhaps powerpc...

Simon.