[gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

The perl-module.eclass must be updated to support EAPI=3 [1] and
a new eclass will be added which does contain some (more or less) useful
stand-alone functions split from the old perl-module.eclass without
exporting phase functions.
Functions used in ebuilds that don't need the exported default phases
are perlinfo() and fixlocalpod().


Below is the new eclass, working title is perl-helper.eclass.
A diff between the the current and the new perl-module.eclass can be
found at [2]. Both are in use in the perl-experimental overlay [3].


Please review! If someone can come up with better names, either the
perl-helper.eclass or the functions named perl_*, please tell me.
I tried to make the perl-helper functions more unique but the
meaningfulness is open to question.


Thanks


[1] https://bugs.gentoo.org/310453
[2] http://dev.gentoo.org/~tove/files/perl-module.diff
[3] http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=tree;f=eclass;hb=HEAD



# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

[[ ${CATEGORY} == "perl-core" ]] && inherit alternatives

perlinfo() {
	debug-print-function $FUNCNAME "$@"
	perl_set_version
}

perl_set_version() {
	debug-print-function $FUNCNAME "$@"
	debug-print "$FUNCNAME: perlinfo_done=${perlinfo_done}"
	${perlinfo_done} && return 0
	perlinfo_done=true

	local f version install{{site,vendor}{arch,lib},archlib}
	eval "$(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )"
	PERL_VERSION=${version}
	SITE_ARCH=${installsitearch}
	SITE_LIB=${installsitelib}
	ARCH_LIB=${installarchlib}
	VENDOR_LIB=${installvendorlib}
	VENDOR_ARCH=${installvendorarch}
}

fixlocalpod() {
	debug-print-function $FUNCNAME "$@"
	perl_delete_localpod
}

perl_delete_localpod() {
	debug-print-function $FUNCNAME "$@"

	find "${D}" -type f -name perllocal.pod -delete
	find "${D}" -depth -mindepth 1 -type d -empty -delete
}

perl_fix_osx_extra() {
	debug-print-function $FUNCNAME "$@"

	# Remove "AppleDouble encoded Macintosh file"
	local f
	find "${S}" -type f -name "._*" -print0 | while read -rd '' f ; do
		einfo "Removing AppleDouble encoded Macintosh file: ${f#${S}/}"
		rm -f "${f}"
		f=${f#${S}/}
	#	f=${f//\//\/}
	#	f=${f//\./\.}
	#	sed -i "/${f}/d" "${S}"/MANIFEST || die
		grep -q "${f}" "${S}"/MANIFEST && \
			elog "AppleDouble encoded Macintosh file in MANIFEST: ${f#${S}/}"
	done
}

perl_delete_module_manpages() {
	debug-print-function $FUNCNAME "$@"

	perl_set_eprefix

	if [[ -d "${ED}"/usr/share/man ]] ; then
#		einfo "Cleaning out stray man files"
		find "${ED}"/usr/share/man -type f -name "*.3pm" -delete
		find "${ED}"/usr/share/man -depth -type d -empty -delete
	fi
}

perl_delete_packlist() {
	debug-print-function $FUNCNAME "$@"
	perl_set_version
	if [[ -d ${D}/${VENDOR_LIB} ]] ; then
		find "${D}/${VENDOR_LIB}" -type f -a \( -name .packlist \
			-o \( -name '*.bs' -a -empty \) \) -delete
		find "${D}/${VENDOR_LIB}" -depth -mindepth 1 -type d -empty -delete
	fi
}

perl_remove_temppath() {
	debug-print-function $FUNCNAME "$@"

	find "${D}" -type f -not -name '*.so' -print0 | while read -rd '' f ; do
		if file "${f}" | grep -q -i " text" ; then
			grep -q "${D}" "${f}" && ewarn "QA: File contains a temporary path ${f}"
			sed -i -e "s:${D}:/:g" "${f}"
		fi
	done
}

perl_link_duallife_scripts() {
	debug-print-function $FUNCNAME "$@"
	if [[ ${CATEGORY} != perl-core ]] || ! has_version ">=dev-lang/perl-5.8.8-r8" ; then
		return 0
	fi

	perl_set_eprefix

	local i ff
	if has "${EBUILD_PHASE:-none}" "postinst" "postrm" ; then
		for i in "${DUALLIFESCRIPTS[@]}" ; do
			alternatives_auto_makesym "/usr/bin/${i}" "/usr/bin/${i}-[0-9]*"
			ff=`echo "${EROOT}"/usr/share/man/man1/${i}-${PV}-${P}.1*`
			ff=${ff##*.1}
			alternatives_auto_makesym "/usr/share/man/man1/${i}.1${ff}" "/usr/share/man/man1/${i}-[0-9]*"
		done
	else
		pushd "${ED}" > /dev/null
		for i in $(find usr/bin -maxdepth 1 -type f 2>/dev/null) ; do
			mv ${i}{,-${PV}-${P}} || die
			DUALLIFESCRIPTS[${#DUALLIFESCRIPTS[*]}]=${i##*/}
			if [[ -f usr/share/man/man1/${i##*/}.1 ]] ; then
				mv usr/share/man/man1/${i##*/}{.1,-${PV}-${P}.1} || die
			fi
		done
		popd > /dev/null
	fi
}

perl_set_eprefix() {
	debug-print-function $FUNCNAME "$@"
	case ${EAPI:-0} in
		0|1|2)
			if ! use prefix; then
				EPREFIX=
				ED=${D}
				EROOT=${ROOT}
			fi
			;;
	esac
}

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Alec Warner]

On Tue, Mar 30, 2010 at 4:11 AM, Torsten Veller <ml-en@veller.net> wrote:
> The perl-module.eclass must be updated to support EAPI=3 [1] and
> a new eclass will be added which does contain some (more or less) useful
> stand-alone functions split from the old perl-module.eclass without
> exporting phase functions.
> Functions used in ebuilds that don't need the exported default phases
> are perlinfo() and fixlocalpod().
>
>
> Below is the new eclass, working title is perl-helper.eclass.
> A diff between the the current and the new perl-module.eclass can be
> found at [2]. Both are in use in the perl-experimental overlay [3].
>
>
> Please review! If someone can come up with better names, either the
> perl-helper.eclass or the functions named perl_*, please tell me.
> I tried to make the perl-helper functions more unique but the
> meaningfulness is open to question.

It is obvious what many of the functions do (I can read shell, yay!)
but it is not obvious to me why they exist or why I would want to call
them.  Why do I want to delete AppleDouble files?  What are dual-life
scripts and why do I want to symlink them?  Why would I want to delete
packfiles?  Some documentation would be nice h ere.

-A

>
>
> Thanks
>
>
> [1] https://bugs.gentoo.org/310453
> [2] http://dev.gentoo.org/~tove/files/perl-module.diff
> [3] http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=tree;f=eclass;hb=HEAD
>
>
>
> # Copyright 1999-2010 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> [[ ${CATEGORY} == "perl-core" ]] && inherit alternatives
>
> perlinfo() {
>        debug-print-function $FUNCNAME "$@"
>        perl_set_version
> }
>
> perl_set_version() {
>        debug-print-function $FUNCNAME "$@"
>        debug-print "$FUNCNAME: perlinfo_done=${perlinfo_done}"
>        ${perlinfo_done} && return 0
>        perlinfo_done=true
>
>        local f version install{{site,vendor}{arch,lib},archlib}
>        eval "$(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )"
>        PERL_VERSION=${version}
>        SITE_ARCH=${installsitearch}
>        SITE_LIB=${installsitelib}
>        ARCH_LIB=${installarchlib}
>        VENDOR_LIB=${installvendorlib}
>        VENDOR_ARCH=${installvendorarch}
> }
>
> fixlocalpod() {
>        debug-print-function $FUNCNAME "$@"
>        perl_delete_localpod
> }
>
> perl_delete_localpod() {
>        debug-print-function $FUNCNAME "$@"
>
>        find "${D}" -type f -name perllocal.pod -delete
>        find "${D}" -depth -mindepth 1 -type d -empty -delete
> }
>
> perl_fix_osx_extra() {
>        debug-print-function $FUNCNAME "$@"
>
>        # Remove "AppleDouble encoded Macintosh file"
>        local f
>        find "${S}" -type f -name "._*" -print0 | while read -rd '' f ; do
>                einfo "Removing AppleDouble encoded Macintosh file: ${f#${S}/}"
>                rm -f "${f}"
>                f=${f#${S}/}
>        #       f=${f//\//\/}
>        #       f=${f//\./\.}
>        #       sed -i "/${f}/d" "${S}"/MANIFEST || die
>                grep -q "${f}" "${S}"/MANIFEST && \
>                        elog "AppleDouble encoded Macintosh file in MANIFEST: ${f#${S}/}"
>        done
> }
>
> perl_delete_module_manpages() {
>        debug-print-function $FUNCNAME "$@"
>
>        perl_set_eprefix
>
>        if [[ -d "${ED}"/usr/share/man ]] ; then
> #               einfo "Cleaning out stray man files"
>                find "${ED}"/usr/share/man -type f -name "*.3pm" -delete
>                find "${ED}"/usr/share/man -depth -type d -empty -delete
>        fi
> }
>
> perl_delete_packlist() {
>        debug-print-function $FUNCNAME "$@"
>        perl_set_version
>        if [[ -d ${D}/${VENDOR_LIB} ]] ; then
>                find "${D}/${VENDOR_LIB}" -type f -a \( -name .packlist \
>                        -o \( -name '*.bs' -a -empty \) \) -delete
>                find "${D}/${VENDOR_LIB}" -depth -mindepth 1 -type d -empty -delete
>        fi
> }
>
> perl_remove_temppath() {
>        debug-print-function $FUNCNAME "$@"
>
>        find "${D}" -type f -not -name '*.so' -print0 | while read -rd '' f ; do
>                if file "${f}" | grep -q -i " text" ; then
>                        grep -q "${D}" "${f}" && ewarn "QA: File contains a temporary path ${f}"
>                        sed -i -e "s:${D}:/:g" "${f}"
>                fi
>        done
> }
>
> perl_link_duallife_scripts() {
>        debug-print-function $FUNCNAME "$@"
>        if [[ ${CATEGORY} != perl-core ]] || ! has_version ">=dev-lang/perl-5.8.8-r8" ; then
>                return 0
>        fi
>
>        perl_set_eprefix
>
>        local i ff
>        if has "${EBUILD_PHASE:-none}" "postinst" "postrm" ; then
>                for i in "${DUALLIFESCRIPTS[@]}" ; do
>                        alternatives_auto_makesym "/usr/bin/${i}" "/usr/bin/${i}-[0-9]*"
>                        ff=`echo "${EROOT}"/usr/share/man/man1/${i}-${PV}-${P}.1*`
>                        ff=${ff##*.1}
>                        alternatives_auto_makesym "/usr/share/man/man1/${i}.1${ff}" "/usr/share/man/man1/${i}-[0-9]*"
>                done
>        else
>                pushd "${ED}" > /dev/null
>                for i in $(find usr/bin -maxdepth 1 -type f 2>/dev/null) ; do
>                        mv ${i}{,-${PV}-${P}} || die
>                        DUALLIFESCRIPTS[${#DUALLIFESCRIPTS[*]}]=${i##*/}
>                        if [[ -f usr/share/man/man1/${i##*/}.1 ]] ; then
>                                mv usr/share/man/man1/${i##*/}{.1,-${PV}-${P}.1} || die
>                        fi
>                done
>                popd > /dev/null
>        fi
> }
>
> perl_set_eprefix() {
>        debug-print-function $FUNCNAME "$@"
>        case ${EAPI:-0} in
>                0|1|2)
>                        if ! use prefix; then
>                                EPREFIX=
>                                ED=${D}
>                                EROOT=${ROOT}
>                        fi
>                        ;;
>        esac
> }
>
>

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "TV" == Torsten Veller <ml-en@veller.net> writes:

One change the perl eclasses require is elimination of the code which
deletes the man pages.

Deleting the man pages is /extremely/ rude and should not occur.

And given that portage inappropriately ignores a fixed eclass in the
OVERlay, that means that every time one syncs one must re-patch the
offending eclasses.

This would be an excellent time to push a fix to the perl eclasses.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Jonathan Callen]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On 04/01/2010 07:41 PM, James Cloos wrote:
> And given that portage inappropriately ignores a fixed eclass in the
> OVERlay, that means that every time one syncs one must re-patch the
> offending eclasses.

If you want all ebuilds to use eclasses from a given overlay (if available)
instead of the eclasses from the same repository, then you should add the
following 2 lines to /etc/portage/repos.conf:

[DEFAULT]
eclass-overrides = local

Where "local" is the contents of /path/to/overlay/profiles/repo_name.

-- 
Jonathan Callen


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Zac Medico]

On 04/01/2010 04:41 PM, James Cloos wrote:
> And given that portage inappropriately ignores a fixed eclass in the
> OVERlay, that means that every time one syncs one must re-patch the
> offending eclasses.

You can configure eclass override behavior via eclass-overrides in
/etc/portage/repos.conf, as documented in `man portage`. There are a
number of caveats to eclass-overrides, and that's why it's not the
default behavior. For example, beware that you'll need to set
PORTAGE_RSYNC_EXTRA_OPTS="--exclude=/metadata/cache" if your overlay
eclasses modify any ebuild metadata (as documented in `man portage`).
-- 
Thanks,
Zac

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Thu, Apr 01, 2010 at 05:14:20PM -0700, Zac Medico wrote:
> You can configure eclass override behavior via eclass-overrides in
> /etc/portage/repos.conf, as documented in `man portage`. There are a
> number of caveats to eclass-overrides, and that's why it's not the
> default behavior. For example, beware that you'll need to set
> PORTAGE_RSYNC_EXTRA_OPTS="--exclude=/metadata/cache" if your overlay
> eclasses modify any ebuild metadata (as documented in `man portage`).

Why not add some boolean list to the repo definition controlling that, 
rather then requiring people to specify the raw RSYNC option?  
Something like REPO_OPTIONS='exclude-cache'?

You can also jam some other options in there- one that might be useful 
for folks is specifying the minimal sync period (sync this repo at 
most once a day, or at most once an hour), etc.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Zac Medico]

On 04/01/2010 05:17 PM, Brian Harring wrote:
> On Thu, Apr 01, 2010 at 05:14:20PM -0700, Zac Medico wrote:
>> You can configure eclass override behavior via eclass-overrides in
>> /etc/portage/repos.conf, as documented in `man portage`. There are a
>> number of caveats to eclass-overrides, and that's why it's not the
>> default behavior. For example, beware that you'll need to set
>> PORTAGE_RSYNC_EXTRA_OPTS="--exclude=/metadata/cache" if your overlay
>> eclasses modify any ebuild metadata (as documented in `man portage`).
> 
> Why not add some boolean list to the repo definition controlling that, 
> rather then requiring people to specify the raw RSYNC option?  
> Something like REPO_OPTIONS='exclude-cache'?
> 
> You can also jam some other options in there- one that might be useful 
> for folks is specifying the minimal sync period (sync this repo at 
> most once a day, or at most once an hour), etc.

I think it would be preferable to extend the cache format to improve
the validation mechanism, as discussed here:


http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml

That said, I wouldn't be opposed to adding something like the
REPO_OPTIONS='exclude-cache' approach that you suggest.
-- 
Thanks,
Zac

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

* James Cloos <cloos@jhcloos.com>:
> One change the perl eclasses require is elimination of the code which
> deletes the man pages.
> 
> Deleting the man pages is /extremely/ rude and should not occur.

There was a reason why the man-pages were removed: I think it was
collisions protection and perl people use `perldoc` anyway.

Do we need a patch to avoid collisions? Do you have it ready and tested?

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

* Alec Warner <antarus@gentoo.org>:
> It is obvious what many of the functions do (I can read shell, yay!)
> but it is not obvious to me why they exist or why I would want to call
> them.  Why do I want to delete AppleDouble files?  What are dual-life
> scripts and why do I want to symlink them?  Why would I want to delete
> packfiles?  Some documentation would be nice h ere.

Absolutely. The perl-team already has a bug for it (#259815).
Perl eclass changes are tracked in bug #239510.
But I don't think missing documentation is a stopper here. Most of it
is copied from perl-modules.eclass.

- AppleDouble (name reported by `file`)
  268497 [perl@gentoo.org] - Remove ._* files in perl-module_src_prepare
  273104 [dev-portage@gentoo.org] - New QA check: installed OSX fork files (if I got the name right)

- dual-life scripts
  scripts installed by dual-life packages (part of dev-lang/perl and
  also stand-alone in perl-core/). Only relevant for perl-core/
  packages.

- .packlist
  something like CONTENTS.

[---=| TOFU protection by t-prot: 143 lines snipped |=---]

Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Michael Higgins]

On Sat, 3 Apr 2010 12:33:48 +0200
Torsten Veller <ml-en@veller.net> wrote:

>  perl people use `perldoc` anyway.

Yep. Why have a man page for a perl module? OTOH, if there is something
that goes in /usr/bin, it should get a man page if there is one. But
not for the modules themselves -- that's not needed at all.

Just my $0.02.

-- 
 |\  /|        |   |          ~ ~  
 | \/ |        |---|          `|` ?
 |    |ichael  |   |iggins    \^ /
 michael.higgins[at]evolone[dot]org

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:

ZM> You can configure eclass override behavior via eclass-overrides in
ZM> /etc/portage/repos.conf, as documented in `man portage`.

,----< From that manpage >
| When using eclass-overrides, due to bug #276264, you must ensure that
| your portage tree does not contain a metadata/cache/ directory.
`----

Which translates into "eclass-orderrides are completely and entirely
useless, so don't bother.

Portage used to used to search for eclasses starting in the top overlay;
it should not have changed.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "TV" == Torsten Veller <ml-en@veller.net> writes:

TV> * James Cloos <cloos@jhcloos.com>:
>> One change the perl eclasses require is elimination of the code which
>> deletes the man pages.
>> 
>> Deleting the man pages is /extremely/ rude and should not occur.

TV> There was a reason why the man-pages were removed: I think it was
TV> collisions protection and perl people use `perldoc` anyway.

Perl people -- I'm one -- use man(1); given the differences in
usefulness, I cannot imagine why anyone would prefer perldoc(1)
over man(1).

TV> Do we need a patch to avoid collisions? Do you have it ready and tested?

I've never seen any collisions due to installing the man pages.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "MH" == Michael Higgins <linux@evolone.org> writes:

MH> Yep. Why have a man page for a perl module? OTOH, if there is something
MH> that goes in /usr/bin, it should get a man page if there is one. But
MH> not for the modules themselves -- that's not needed at all.

Because man(1) works better than the alternatives; it is the unix way;
it is the first thing one types when searching for documentation.

The idea that the man pages are somehow uneeded is incomprehensible.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Duncan]

James Cloos posted on Tue, 06 Apr 2010 10:27:36 -0400 as excerpted:

>>>>>> "MH" == Michael Higgins <linux@evolone.org> writes:
> 
> MH> Yep. Why have a man page for a perl module? OTOH, if there is
> something MH> that goes in /usr/bin, it should get a man page if there
> is one. But MH> not for the modules themselves -- that's not needed at
> all.
> 
> Because man(1) works better than the alternatives; it is the unix way;
> it is the first thing one types when searching for documentation.
> 
> The idea that the man pages are somehow uneeded is incomprehensible.

While you're correct in the ordinary case, keep in mind that this is perl 
developer docs we're talking about here -- not ordinary user documentation.

And those that know enough about perl to find the developer documentation 
useful should also know how to use perldoc, while those that don't know 
how to use perldoc, aren't likely to find the perl developer manpages of 
much help, either; they'll be pretty much ordinary users, at least where 
perl is concerned, and thus if anything, confused and irritated by all 
those extra "useless" perl developer manpages.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Tue, 06 Apr 2010 10:25:27 -0400
James Cloos <cloos@jhcloos.com> wrote:

> Perl people -- I'm one -- use man(1); given the differences in
> usefulness, I cannot imagine why anyone would prefer perldoc(1)
> over man(1).

I prefer perldoc over man. And I cannot imagine why anyone would prefer
keeping two copies of the same docs if generating one from another
takes less than a second.

-- 
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Zac Medico]

On 04/06/2010 07:22 AM, James Cloos wrote:
>>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:
> 
> ZM> You can configure eclass override behavior via eclass-overrides in
> ZM> /etc/portage/repos.conf, as documented in `man portage`.
> 
> ,----< From that manpage >
> | When using eclass-overrides, due to bug #276264, you must ensure that
> | your portage tree does not contain a metadata/cache/ directory.
> `----
> 
> Which translates into "eclass-orderrides are completely and entirely
> useless, so don't bother.

Well, it's roughly equivalent to the old default behavior (which you
apparently preferred). However, the issue is now complicated by the
fact that FEATURES=metadata-transfer is disabled by default, so when
portage goes to pull cache directly from metadata/cache/, it won't
be able to validate eclass changes since there are no eclass
timestamps saved inside metadata/cache/. FWIW, there was some
discussion about extending the cache format to improve
the validation mechanism for eclasses here:

http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml

> Portage used to used to search for eclasses starting in the top overlay;
> it should not have changed.

Well, the biggest caveat to that behavior is that it tends to
invalidate metadata cache as reported in this bug:

  http://bugs.gentoo.org/show_bug.cgi?id=124041

I'd be happy to work on resolving issues with eclass-orderrides to
make it more usable. However, due to the need to regenerate metadata
cache, I don't think that this is something that can ever again be
enabled by default.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "MG" == Michał Górny <gentoo@mgorny.alt.pl> writes:

MG> I prefer perldoc over man. And I cannot imagine why anyone would prefer
MG> keeping two copies of the same docs if generating one from another
MG> takes less than a second.

It takes more than a mere second, and man(1), man.el, woman.el and the
like have better UIs than perldoc(1) has.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "D" == Duncan  <1i5t5.duncan@cox.net> writes:

D> While you're correct in the ordinary case, keep in mind that this is perl 
D> developer docs we're talking about here -- not ordinary user documentation.

Developer docs *are* ordinary user documentation.  Section 3 is perhaps
the most used section of man, with sections 2 and, depending on platform,
one or more of sections 4, 5 or 6 following.

D> And those that know enough about perl to find the developer documentation 
D> useful should also know how to use perldoc,

You are ignoring the fact that having the docs in man is more useful;
much easier to use, usable by any man reader.  The list goes on.

There is simply no *real* benefit to eliding them, it only does harm.

People who do not want to install them should specify that preference
via a USE flag (-man, perhaps).

It would even be OK were the USE flag off by default; but making it
impossible to Do The Right Thing w/o editing eclasses every time one
syncs is just wrong.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

Hi,

Torsten Veller <ml-en@veller.net>:
> 	find "${S}" -type f -name "._*" -print0 | while read -rd ''
> f ; do einfo "Removing AppleDouble encoded Macintosh file: ${f#${S}/}"
> 		rm -f "${f}"
> 		f=${f#${S}/}
> 	#	f=${f//\//\/}
> 	#	f=${f//\./\.}
> 	#	sed -i "/${f}/d" "${S}"/MANIFEST || die
> 		grep -q "${f}" "${S}"/MANIFEST && \
> 			elog "AppleDouble encoded Macintosh file in
> MANIFEST: ${f#${S}/}" done
> }

 Are those f= lines commented?  And what was their purpose?  Can they
be deleted?

> 	if [[ -d ${D}/${VENDOR_LIB} ]] ; then

 Haven't checked, but quotes not needed?

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Fabian Groffen]

On 12-04-2010 10:07:54 +0200, Christian Faulhammer wrote:
> > 	if [[ -d ${D}/${VENDOR_LIB} ]] ; then
> 
>  Haven't checked, but quotes not needed?

it's within [[ ]], so no.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:

ZM> On 04/06/2010 07:22 AM, James Cloos wrote:
>>>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:
>> 
ZM> You can configure eclass override behavior via eclass-overrides in
ZM> /etc/portage/repos.conf, as documented in `man portage`.
>> 
>> ,----< From that manpage >
>> | When using eclass-overrides, due to bug #276264, you must ensure that
>> | your portage tree does not contain a metadata/cache/ directory.
>> `----
>> 
>> Which translates into "eclass-orderrides are completely and entirely
>> useless, so don't bother.

ZM> Well, it's roughly equivalent to the old default behavior (which you
ZM> apparently preferred). However, the issue is now complicated by the
ZM> fact that FEATURES=metadata-transfer is disabled by default, so when
ZM> portage goes to pull cache directly from metadata/cache/, it won't
ZM> be able to validate eclass changes since there are no eclass
ZM> timestamps saved inside metadata/cache/.

Portage does not need to validate eclass changes.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

A reasonable alternative would be to have a separate variable in make.conf,
such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses.

In most cases, users would probably only have their own, local overlay there,
and any eclasses found there should be used in preference to any in portage
or in the overlay the ebuild came from, if applicable.

Every time portage looks for an eclass, it should check there first (caching
what it found, to save future lookups w/in that run) and just use anything
it finds.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On Mon, Apr 12, 2010 at 01:30:21PM -0400, James Cloos wrote:
> A reasonable alternative would be to have a separate variable in make.conf,
> such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses.
> 
> In most cases, users would probably only have their own, local overlay there,
> and any eclasses found there should be used in preference to any in portage
> or in the overlay the ebuild came from, if applicable.
> 
> Every time portage looks for an eclass, it should check there first (caching
> what it found, to save future lookups w/in that run) and just use anything
> it finds.

repos.conf has functionality of this sort, although you'll have to 
consult the man page for the exact option name...
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Zac Medico]

On 04/12/2010 10:17 AM, James Cloos wrote:
>>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:
> 
> ZM> On 04/06/2010 07:22 AM, James Cloos wrote:
>>>>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:
>>>
> ZM> You can configure eclass override behavior via eclass-overrides in
> ZM> /etc/portage/repos.conf, as documented in `man portage`.
>>>
>>> ,----< From that manpage >
>>> | When using eclass-overrides, due to bug #276264, you must ensure that
>>> | your portage tree does not contain a metadata/cache/ directory.
>>> `----
>>>
>>> Which translates into "eclass-orderrides are completely and entirely
>>> useless, so don't bother.
> 
> ZM> Well, it's roughly equivalent to the old default behavior (which you
> ZM> apparently preferred). However, the issue is now complicated by the
> ZM> fact that FEATURES=metadata-transfer is disabled by default, so when
> ZM> portage goes to pull cache directly from metadata/cache/, it won't
> ZM> be able to validate eclass changes since there are no eclass
> ZM> timestamps saved inside metadata/cache/.
> 
> Portage does not need to validate eclass changes.

Then how do you propose that it handles metadata changes that are
attributed to eclass changes? For example, see the issue they had
with vmware.eclass changes in this bug:

  http://bugs.gentoo.org/show_bug.cgi?id=139134
-- 
Thanks,
Zac

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Zac Medico]

On 04/12/2010 11:00 AM, Brian Harring wrote:
> On Mon, Apr 12, 2010 at 01:30:21PM -0400, James Cloos wrote:
>> A reasonable alternative would be to have a separate variable in make.conf,
>> such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses.
>>
>> In most cases, users would probably only have their own, local overlay there,
>> and any eclasses found there should be used in preference to any in portage
>> or in the overlay the ebuild came from, if applicable.
>>
>> Every time portage looks for an eclass, it should check there first (caching
>> what it found, to save future lookups w/in that run) and just use anything
>> it finds.
> 
> repos.conf has functionality of this sort, although you'll have to 
> consult the man page for the exact option name...

It's called eclass-overrides and it's been mentioned earlier in the
thread.
-- 
Thanks,
Zac

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:

ZM> It's called eclass-overrides and it's been mentioned earlier in the thread.

But that is useless unless you ignore the metadata cache.  And ignoring the
metadata cache makes portage unusably slow.

It needs to work exacly as I described it.

And lets not forget that the current situation is in fact a regression.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "ZM" == Zac Medico <zmedico@gentoo.org> writes:

>> Portage does not need to validate eclass changes.

ZM> Then how do you propose that it handles metadata changes that are
ZM> attributed to eclass changes? For example, see the issue they had
ZM> with vmware.eclass changes in this bug:

ZM>   http://bugs.gentoo.org/show_bug.cgi?id=139134

OK.  Let me rephrase.  Portage does not need to validate local changes.

If a user uses a local eclass to override one in portage or in some
remote overlay s/he follows, it is his/er responsibility to update
it when the original undergoes major renovation.

All portage needs to do is accept that local overrides are more
important than anything coming from upstream.

And do so w/o making it impossible to use caches for everything
which does not have a local override.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Fri, 16 Apr 2010 16:23:48 -0400
James Cloos <cloos@jhcloos.com> wrote:
> OK.  Let me rephrase.  Portage does not need to validate local
> changes.

Sure it does. If it doesn't, and your local changes affect metadata,
horrible things happen.

> If a user uses a local eclass to override one in portage or in some
> remote overlay s/he follows, it is his/er responsibility to update
> it when the original undergoes major renovation.

Users aren't responsible...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Steev Klimaszewski]

On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 16 Apr 2010 16:23:48 -0400
> James Cloos <cloos@jhcloos.com> wrote:
>> OK.  Let me rephrase.  Portage does not need to validate local
>> changes.
>
> Sure it does. If it doesn't, and your local changes affect metadata,
> horrible things happen.

Why not check the mtime on the overlay, if it is older than last sync
time, not invalid.

>> If a user uses a local eclass to override one in portage or in some
>> remote overlay s/he follows, it is his/er responsibility to update
>> it when the original undergoes major renovation.
>
> Users aren't responsible...

And doing everything we can to make them not be isn't going to teach
them anything.

> --
> Ciaran McCreesh
>

Steev

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

On Fri, 16 Apr 2010 22:30:46 -0500
Steev Klimaszewski <steev@gentoo.org> wrote:
> On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Fri, 16 Apr 2010 16:23:48 -0400
> > James Cloos <cloos@jhcloos.com> wrote:
> >> OK.  Let me rephrase.  Portage does not need to validate local
> >> changes.
> >
> > Sure it does. If it doesn't, and your local changes affect metadata,
> > horrible things happen.
> 
> Why not check the mtime on the overlay, if it is older than last sync
> time, not invalid.

Because it can still be invalid if you do that. If you're using a repo
with pregenerated cache with an eclass from a different repo than the
one used do the pregenerating, the pregenerated cache is always invalid.

> >> If a user uses a local eclass to override one in portage or in some
> >> remote overlay s/he follows, it is his/er responsibility to update
> >> it when the original undergoes major renovation.
> >
> > Users aren't responsible...
> 
> And doing everything we can to make them not be isn't going to teach
> them anything.

Which is why you design a system that just gets things right, rather
than one that relies upon users getting things right.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

* James Cloos <cloos@jhcloos.com>:
> >>>>> "TV" == Torsten Veller <ml-en@veller.net> writes:
> TV> There was a reason why the man-pages were removed: I think it was
> TV> collisions protection and perl people use `perldoc` anyway.
> 
> Perl people -- I'm one -- use man(1); given the differences in
> usefulness, I cannot imagine why anyone would prefer perldoc(1)
> over man(1).

Please file a bug if you want man pages for all the modules.

Thanks

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:

CM> Users aren't responsible...

Even if that is or were so, it is irrelevant.  It is ther user's box,
and therefore the users' preference is the only valid choice.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Sat, 17 Apr 2010 23:28:17 -0400
James Cloos <cloos@jhcloos.com> wrote:
> >>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:
> 
> CM> Users aren't responsible...
> 
> Even if that is or were so, it is irrelevant.  It is ther user's box,
> and therefore the users' preference is the only valid choice.

There's no need to offer the user the choice to do something that is
always broken. Your car doesn't have a "connect the exhaust fumes to
the air conditioning intake" button.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:

CM> There's no need to offer the user the choice to do something that is
CM> always broken. Your car doesn't have a "connect the exhaust fumes to
CM> the air conditioning intake" button.

Overriding portage's eclasses with one's own is not "always broken";
your analogy is not at all on point.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Harald van Dijk]

On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote:
> >>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:
> 
> CM> There's no need to offer the user the choice to do something that is
> CM> always broken. Your car doesn't have a "connect the exhaust fumes to
> CM> the air conditioning intake" button.
> 
> Overriding portage's eclasses with one's own is not "always broken";
> your analogy is not at all on point.

Overriding portage's eclasses with your own is already possible. You're
asking to override portage's eclasses, without letting portage handle
the fact that you are overriding eclasses. And that is a bad idea. You
haven't commented, at least not in this thread that I have seen, on
how to handle metadata changes as a result of eclass changes.

Let's say this is in the tree:

foo.eclass:
DEPEND="dev-lang/python:2.6"

bar-1.ebuild:
inherit foo

Let's say this is in your overlay:

foo.eclass:
DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )"

Now you install bar. How should portage know that it must regenerate the
metadata cache, to see that it doesn't need to install python 2.6 if you
already have 3.1?

[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass

[Torsten Veller]

* Torsten Veller <ml-en@veller.net>:
> The perl-module.eclass must be updated to support EAPI=3 [1] and
> a new eclass will be added which does contain some (more or less) useful
> stand-alone functions split from the old perl-module.eclass without
> exporting phase functions.

Somehow I was sleeping: It's more useful to set EXPORT_FUNCTIONS
conditionally and have all functions in perl-module.eclass.

I think this justifies the elimination of the perl-helper.eclass.

Sorry for the confusion. Hopefully wide awake now.



New perl-helper.eclass:

| # Copyright 1999-2010 Gentoo Foundation
| # Distributed under the terms of the GNU General Public License v2
| # $Header: $
| 
| # @DEAD
| 
| PERL_EXPORT_PHASE_FUNCTIONS=no
| inherit perl-module


Head of new perl-module.eclass:
http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=tree;f=eclass;hb=HEAD

| @@ -12,19 +12,19 @@
|  # The perl-module eclass is designed to allow easier installation of perl
|  # modules, and their incorporation into the Gentoo Linux system.
|  
| -inherit perl-helper eutils base
| +inherit eutils base
|  [[ ${CATEGORY} == "perl-core" ]] && inherit alternatives
|  
|  PERL_EXPF="src_unpack src_compile src_test src_install"
|  
|  case "${EAPI:-0}" in
|         0|1)
| -               PERL_EXPF="${PERL_EXPF} pkg_setup pkg_preinst pkg_postinst pkg_prerm pkg_postrm"
| +               PERL_EXPF+=" pkg_setup pkg_preinst pkg_postinst pkg_prerm pkg_postrm"
|                 ;;
|         2|3)
| -               PERL_EXPF="${PERL_EXPF} src_prepare src_configure"
| +               PERL_EXPF+=" src_prepare src_configure"
|                 [[ ${CATEGORY} == "perl-core" ]] && \
| -                       PERL_EXPF="${PERL_EXPF} pkg_postinst pkg_postrm"
| +                       PERL_EXPF+=" pkg_postinst pkg_postrm"
|  
|                 case "${GENTOO_DEPEND_ON_PERL:-yes}" in
|                         yes)
| @@ -38,7 +38,17 @@ case "${EAPI:-0}" in
|                 ;;
|  esac
|  
| -EXPORT_FUNCTIONS ${PERL_EXPF}
| +case "${PERL_EXPORT_PHASE_FUNCTIONS:-yes}" in
| +       yes)
| +               EXPORT_FUNCTIONS ${PERL_EXPF}
| +               ;;
| +       no)
| +               debug-print "PERL_EXPORT_PHASE_FUNCTIONS=no"
| +               ;;
| +       *)
| +               DEPEND+=" PERL_EXPORT_PHASE_FUNCTIONS-UNSUPPORTED"
| +               ;;
| +esac
|  
|  DESCRIPTION="Based on the $ECLASS eclass"
...

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[James Cloos]

>>>>> "HvD" == Harald van Dijk <truedfx@gentoo.org> writes:

HvD> Let's say this is in the tree:

HvD> foo.eclass:
HvD> DEPEND="dev-lang/python:2.6"

HvD> bar-1.ebuild:
HvD> inherit foo

HvD> Let's say this is in your overlay:

HvD> foo.eclass:
HvD> DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )"

HvD> Now you install bar. How should portage know that it must regenerate the
HvD> metadata cache, to see that it doesn't need to install python 2.6 if you
HvD> already have 3.1?

It shouldn't bother. :)

Really, that isn't the kind of change that I find I need to make.

And it should never regenerate the metadata cache (ie portage/metadata/cache).
The docs used to -- and probably still do -- recommend regenerating that
cache after certain changes.  Which is a drasticly bogus suggestion unless
you have a *very* fast system.  Even across a dialup straw, an emerge --sync
is orders of magnitude faster.

If the ebuild calls a class which has been overridden by a local class, and
the original class set DEPENDs or the like, then as it reads in the new class
file it should just use those values in place of the ones in the cache.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

[Zac Medico]

On 04/23/2010 08:14 AM, James Cloos wrote:
>>>>>> "HvD" == Harald van Dijk <truedfx@gentoo.org> writes:
> 
> HvD> Let's say this is in the tree:
> 
> HvD> foo.eclass:
> HvD> DEPEND="dev-lang/python:2.6"
> 
> HvD> bar-1.ebuild:
> HvD> inherit foo
> 
> HvD> Let's say this is in your overlay:
> 
> HvD> foo.eclass:
> HvD> DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )"
> 
> HvD> Now you install bar. How should portage know that it must regenerate the
> HvD> metadata cache, to see that it doesn't need to install python 2.6 if you
> HvD> already have 3.1?
> 
> It shouldn't bother. :)
> 
> Really, that isn't the kind of change that I find I need to make.

Different users have different needs. The user who reported this bug
needed the opposite behavior:

  http://bugs.gentoo.org/show_bug.cgi?id=276264

> And it should never regenerate the metadata cache (ie portage/metadata/cache).

Again, different users have different needs and the user in bug
#276264 really needed to regenerate the cache.

> The docs used to -- and probably still do -- recommend regenerating that
> cache after certain changes.  Which is a drasticly bogus suggestion unless
> you have a *very* fast system.

It's a somewhat bogus suggestion if you are not modifying eclasses
in the same way as the user from bug #276264. Note that it's
possible to enable eclass-overrides without discarding
$PORTDIR/metadata/cache. It seems like that might work for your use
case (don't forget that this won't necessarily be appropriate for
every user).

For the user in bug #276264, it's more appropriate to discard
$PORTDIR/metadata/cache and run emerge --regen (with --jobs if he
wants to use multiple cpu cores in parallel).

> Even across a dialup straw, an emerge --sync
> is orders of magnitude faster.

Different things give different results. It may work for your use
case but not for others.

> If the ebuild calls a class which has been overridden by a local class, and
> the original class set DEPENDs or the like, then as it reads in the new class
> file it should just use those values in place of the ones in the cache.

And that's the behavior that you'll get if you don't discard
$PORTDIR/metadata/cache (which would be inappropriate for the user
in bug #276264).

> 
> -JimC


-- 
Thanks,
Zac