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.
# 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
}
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
}
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
}
03-30-2010, 03:48 PM
Alec Warner
perl eclass review - EAPI=3 + new helper eclass
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.
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
04-02-2010, 12:12 AM
Jonathan Callen
perl eclass review - EAPI=3 + new helper eclass
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
04-02-2010, 12:14 AM
Zac Medico
perl eclass review - EAPI=3 + new helper eclass
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
04-02-2010, 12:17 AM
Brian Harring
perl eclass review - EAPI=3 + new helper eclass
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
04-02-2010, 12:25 AM
Zac Medico
perl eclass review - EAPI=3 + new helper eclass
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:
That said, I wouldn't be opposed to adding something like the
REPO_OPTIONS='exclude-cache' approach that you suggest.
--
Thanks,
Zac
04-03-2010, 10:33 AM
Torsten Veller
perl eclass review - EAPI=3 + new helper eclass
* 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?
04-03-2010, 10:33 AM
Torsten Veller
perl eclass review - EAPI=3 + new helper eclass
* 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 |=---]
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.