Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On 04/23/2010 08:14 AM, James Cloos wrote: HvD == Harald van Dijk true...@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
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
HvD == Harald van Dijk true...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
CM == Ciaran McCreesh ciaran.mccre...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote: CM == Ciaran McCreesh ciaran.mccre...@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?
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Fri, 16 Apr 2010 22:30:46 -0500 Steev Klimaszewski st...@gentoo.org wrote: On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 16 Apr 2010 16:23:48 -0400 James Cloos cl...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
CM == Ciaran McCreesh ciaran.mccre...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
ZM == Zac Medico zmed...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
ZM == Zac Medico zmed...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Fri, 16 Apr 2010 16:23:48 -0400 James Cloos cl...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 16 Apr 2010 16:23:48 -0400 James Cloos cl...@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
ZM == Zac Medico zmed...@gentoo.org writes: ZM On 04/06/2010 07:22 AM, James Cloos wrote: ZM == Zac Medico zmed...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
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 pgp1GRm7vuWL5.pgp Description: PGP signature
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On 04/12/2010 10:17 AM, James Cloos wrote: ZM == Zac Medico zmed...@gentoo.org writes: ZM On 04/06/2010 07:22 AM, James Cloos wrote: ZM == Zac Medico zmed...@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
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
ZM == Zac Medico zmed...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On 04/06/2010 07:22 AM, James Cloos wrote: ZM == Zac Medico zmed...@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] perl eclass review - EAPI=3 + new helper eclass
TV == Torsten Veller ml...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] 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
Re: [gentoo-dev] 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 pgpTRi8nsEWHD.pgp Description: PGP signature
Re: [gentoo-dev] 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: 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
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Tue, Mar 30, 2010 at 4:11 AM, Torsten Veller ml...@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 ${duallifescrip...@]} ; 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
