[gentoo-dev] Re: packages up for grabs
Daniel Drake <[EMAIL PROTECTED]> writes: > dev-dotnet/evolution-sharp I was going to ask you about this last week, I guess I'll look into it (although it makes me feel dirty to work with .NET stuff, I've been working with worse stuff :P). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpg2jdRM4KaJ.pgp Description: PGP signature
Re: [gentoo-dev] DEFAULT_* proposal
В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет: > This is a reposting of a call for discussion on DEFAULT_* variables. > The original discussion was at [1]. How does this proposal answers concerns raised during last discussion? I did my best and reread all the discussions and both proposals. I found two reasons supporting this change is that it makes ebuilds more "flexible"[1] or "much simpler"[2]. With all due respect I disagree. 1. Functions we have now are much more flexible then proposed arrays. Do I need to think of some example of code that is impossible to do with arrays but still possible with functions? 2. Much simpler? No, it's not: (2.1) Such arrays do not not reduce the number of keys to be pressed. They require even more typing for small ebuilds [3] (example proposed by you, btw) and the only example which expose some improvement (presented by Santiago M. Mola[4]) shows that we still didn't learned how to use syntax we already have and (2.2) some extensions to the current syntax will just complicate things. Look if you remove $myconf variable from that ebuild[4], remove || die after econf and in EAPI=2 you can drop emake || die you'll see that the gain is small even for such medium size ebuild. At the same time this new syntax make some things worse: 1. it hides real code under this variables. 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad practice of using patches instead of sed. 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, btw). (highlighting helps here but does not makes that variables easier to read or type in?) 4. "it also conflates multiple concepts into a single variable name (the function name, whether it's USE-dependent, and how the configure flag is passed)." (-- Donnie Berkholz [6]) 5. "One of the great things about ebuilds is that they're very natural to write in most cases, if you can manage to build the program by hand. Raising this barrier of entry for questionable benefit seems like a bad idea." (-- Donnie Berkholz [7]) So, why to reiterate this discussion without providing clear answer to the above concerns? At the same time default src_install is different proposal and having it implemented is a good idea. [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990 [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728 [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990 [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996 [5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061 [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051 -- Peter.
Re: [gentoo-dev] DEFAULT_* proposal
On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote: > В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет: > > This is a reposting of a call for discussion on DEFAULT_* variables. > > The original discussion was at [1]. > 1. Functions we have now are much more flexible then proposed arrays. Do > I need to think of some example of code that is impossible to do with > arrays but still possible with functions? And more complex. Remember, I said that these proposals were not for every case. Showing how it can't be used in one case says nothing about it otherwise being used. > 2. Much simpler? No, it's not: > > (2.1) Such arrays do not not reduce the number of keys to be pressed. > They require even more typing for small ebuilds [3] (example proposed by > you, btw) and the only example which expose some improvement (presented > by Santiago M. Mola[4]) shows that we still didn't learned how to use > syntax we already have and (2.2) some extensions to the current syntax > will just complicate things. Look if you remove $myconf variable from > that ebuild[4], remove || die after econf and in EAPI=2 you can drop > emake || die you'll see that the gain is small even for such medium size > ebuild. > At the same time this new syntax make some things worse: Here's an example of how much gain there is with this approach: http://tinyurl.com/6jj8a5 > 1. it hides real code under this variables. As mentioned, so do use_enable, use_with, emake(though these are functions hiding code, DOCS. Hiding code is not always a bad thing. > 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad > practice of using patches instead of sed. How so? We already have a ton of PATCHES variables as mentioned. How is this standardization of what we already have going to promote bad practices? > 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus > easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, > btw). (highlighting helps here but does not makes that variables easier > to read or type in?) Ok, so you could find a different name. The names aren't really important. You could use USE_ENABLES and USE_WITHS and DEFAULT_PATCHES. > 4. "it also conflates multiple concepts into a single variable name (the > function name, whether it's USE-dependent, and how the configure flag is > passed)." (-- Donnie Berkholz [6]) > > 5. "One of the great things about ebuilds is that they're very natural > to write in most cases, if you can manage to build the program by hand. > Raising this barrier of entry for questionable benefit seems like a bad > idea." (-- Donnie Berkholz [7]) No one is raising the barrier. People can continue to use use_enable and use_with as they have for ages. The only thing that changes is that ebuild devs now have another way(which is simpler from my experience and that of others) to write ebuilds. Also, it's not that more > > So, why to reiterate this discussion without providing clear answer to > the above concerns? > Because we came up with a more comprehensive proposal covering more phase functions. > > At the same time default src_install is different proposal and having it > implemented is a good idea. > > > [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990 > [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728 > [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990 > [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996 > [5] > http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html > [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061 > [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051 > > -- > Peter. > pgp7EgxTeYlsl.pgp Description: PGP signature
Re: [gentoo-dev] DEFAULT_* proposal
Hello, El dom, 09-11-2008 a las 15:39 +0300, Peter Volkov escribió: > > 1. Functions we have now are much more flexible then proposed arrays. Do > I need to think of some example of code that is impossible to do with > arrays but still possible with functions? > The same concern was raised in the default src_install proposal. Making default functions a bit more flexible doesn't mean we need default functions which cover every possible case, that's just impossible. > > At the same time this new syntax make some things worse: > > 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad > practice of using patches instead of sed. As shown in the proposal, this variable is already used in many eclasses and it has been proven useful. I'm not sure the existence of PATCHES is promoting any kind of "patch abuse". As far as I know, it's more common the concern about abusing sed for things that should be patched rather than the other way. But, in any case, both methods would still be available: src_prepare { epatch "${FILESDIR}"/some-stuff.patch sed -i -e "s:FOO:BAR:g" Makefile } would still be correct. If someone is using the PATCHES variable like this: PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... ) a sed call would be easy to add if needed as follows: PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... ) src_prepare() { default sed -i -e "s:FOO:BAR:g" Makefile } It's quite straight-forward. > 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus > easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, > btw). (highlighting helps here but does not makes that variables easier > to read or type in?) This is the easier part to address. If these names are a problem, other names can be used. For example, what it's called DEFAULT_SRC_INSTALL_DOCS in this proposal, it's called just DOCS in others. If people likes this approach better, then similar names can be chosen for the rest of proposed variables. For example: DEFAULT_SRC_PREPARE_PATCHES -> PATCHES, EPATCHES... DEFAULT_SRC_CONFIGURE_ENABLES -> ECONF_ENABLES DEFAULT_SRC_COMPILE_PARAMS -> EMAKE_PARAMS, EMAKE_EXTRA_PARAMS... Anyway, it'd be better if people focus on discussing the actual functionality rather than the chosen names. > > 4. "it also conflates multiple concepts into a single variable name (the > function name, whether it's USE-dependent, and how the configure flag is > passed)." (-- Donnie Berkholz [6]) ECONF_USE_ENABLES might solve that problem. > > 5. "One of the great things about ebuilds is that they're very natural > to write in most cases, if you can manage to build the program by hand. > Raising this barrier of entry for questionable benefit seems like a bad > idea." (-- Donnie Berkholz [7]) Functions would still be overridable. And, in fact, they will need to be overriden in many cases. There's no change there. With respect this "barrier", it already exists with the many eclasses we have. Regards, -- Santiago Moisés Mola Jabber: [EMAIL PROTECTED] | GPG: AAD203B5 signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] DEFAULT_* proposal
Well for myself I found compromise. Although in both proposals as I see you've omitted part where you'll discuss how you are going to implement this feature, implementing this feature as eclass addresses most of my concerns, since: 1. ebuild's syntax does not change 2. people will have to inherit some.eclass to use them and thus will do this only when it's really saves time/efforts I've dropped all other answers I was going to give you since I started to feel that this is just another cycle. We can discuss them off list if necessary. :) -- Peter.
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On Sunday 02 November 2008, Peter Alfredsen wrote: > The attached patch for bug 238753 makes base.eclass support EAPI 2 > functions. Applied -- /PA signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Please review: function epunt_la_files for eutils.eclass
I attach here a proposed new function for eutils.eclass. Review requested. Thanks to zlin and igli for initial review and suggestions on #gentoo-dev-help. -- /PA --- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200 +++ eutils1.eclass 2008-11-06 22:22:51.0 +0100 @@ -1805,5 +1805,37 @@ ) || die else newbin "${tmpwrapper}" "${wrapper}" || die fi } + +# @FUNCTION: epunt_la_files +# @USAGE: [dir to scan] +# @DESCRIPTION: +# .la files can cause many unpleasantries when they disappear, +# forcing rebuilds of seemingly unrelated packages. +# This function removes the .la files from [dir to scan], "${D}" if not set. +# A good time to start punting .la files may be when a .so bump happens, +# so dependent packages do not have to be rebuilt twice. +# +# See also: +# bug 245889 +# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later + +epunt_la_files() { + debug-print-function $FUNCNAME "$@" + local TARGET=$1 + [ -z "${TARGET}" ] && TARGET="${D}" + + # If this is a non-ELF system, chances are good that the .la files will be needed. + if type -P scanelf &> /dev/null + then + debug-print "Scanelf found, proceeding..." + ebegin "Removing useless .la files" + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+' + eend 0 + else + debug-print "scanelf not found, this appears to be a non-ELF system." + debug-print "non-ELF systems are likely to need .la files." + debug-print ".la files not removed from ${TARGET}" + fi +} signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote: > + # If this is a non-ELF system, chances are good that the .la files will > be needed. > + if type -P scanelf &> /dev/null I think this is a not so cool way to check for an ELF system. > + then > + debug-print "Scanelf found, proceeding..." > + ebegin "Removing useless .la files" > + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec > rm -f '{}' '+' > + eend 0 > + else > + debug-print "scanelf not found, this appears to be a non-ELF > system." > + debug-print "non-ELF systems are likely to need .la files." > + debug-print ".la files not removed from ${TARGET}" rationale? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Sunday 09 November 2008, Fabian Groffen wrote: > On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote: > > + # If this is a non-ELF system, chances are good that the .la > > files will be needed. + if type -P scanelf &> /dev/null > > I think this is a not so cool way to check for an ELF system. Indeed, I think it's a horrid way. Please find a better one. > > + then > > + debug-print "Scanelf found, proceeding..." > > + ebegin "Removing useless .la files" > > + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec > > rm -f '{}' '+' +eend 0 > > + else > > + debug-print "scanelf not found, this appears to be a non-ELF > > system." + debug-print "non-ELF systems are likely to need .la > > files." + debug-print ".la files not removed from ${TARGET}" > > rationale? "I've been told" that .la files are really only needed on non-ELF systems and with plugin systems that use dlopen. I actually have no way of knowing that the .la files are needed on those arches, but I had your archs in mind when doing the patch. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 18:34:31 +0200, Peter Alfredsen wrote: > On Sunday 09 November 2008, Fabian Groffen wrote: > > On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote: > > > + # If this is a non-ELF system, chances are good that the .la > > > files will be needed. + if type -P scanelf &> /dev/null > > > > I think this is a not so cool way to check for an ELF system. > > Indeed, I think it's a horrid way. Please find a better one. % uname -a Darwin tefnut.cheops.ods.org 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc PowerMac8,2 Darwin % scanelf --version pax-utils-0.1.18_pre0004: scanelf.c compiled Oct 19 2008 $Id: scanelf.c,v 1.194 2008/09/29 06:05:55 vapier Exp $ scanelf written for Gentoo by % scanmacho --version pax-utils-0.1.18_pre0004: scanmacho.c compiled Oct 19 2008 $Id: scanmacho.c,v 1.5 2008/10/19 18:11:59 grobian Exp $ scanmacho written for Gentoo by You could identify ELF a bit more reliable by running file on e.g. "${ROOT}/bin/bash", or just by building a list of CHOSTs that you know are ELF systems. > > > + debug-print "scanelf not found, this appears to be a non-ELF > > > system." +debug-print "non-ELF systems are likely to need > > > .la > > > files." + debug-print ".la files not removed from ${TARGET}" > > > > rationale? > > "I've been told" that .la files are really only needed on non-ELF > systems and with plugin systems that use dlopen. I actually have no way > of knowing that the .la files are needed on those arches, but I had > your archs in mind when doing the patch. Ok. What worries me though is that this would result in some systems having libtool files whereas the majority does not. E.g. removing them apparently fixes a problem that then crops up on those systems or something. Can't think of any atm. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 09-11-2008 19:46:12 +0200, Peter Alfredsen wrote: > > Ok. What worries me though is that this would result in some systems > > having libtool files whereas the majority does not. E.g. removing > > them apparently fixes a problem that then crops up on those systems > > or something. Can't think of any atm. > > I can. If you have .la files, you will need to revdep-rebuild a lot > more. But c'est la vie. I meant I can't think of an issue when there is no .la file. > --- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200 > +++ eutils1.eclass2008-11-09 18:26:44.0 +0100 > @@ -1805,5 +1805,37 @@ > ) || die > else > newbin "${tmpwrapper}" "${wrapper}" || die > fi > } > + > +# @FUNCTION: epunt_la_files > +# @USAGE: [dir to scan] > +# @DESCRIPTION: > +# .la files can cause many unpleasantries when they disappear, > +# forcing rebuilds of seemingly unrelated packages. > +# This function removes the .la files from [dir to scan], "${D}" if not set. > +# A good time to start punting .la files may be when a .so bump happens, > +# so dependent packages do not have to be rebuilt twice. > +# > +# See also: > +# bug 245889 > +# > http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later > + > +epunt_la_files() { > + debug-print-function $FUNCNAME "$@" > + local TARGET=$1 > + [ -z "${TARGET}" ] && TARGET="${D}" > + > + # If this is a non-ELF system, chances are good that the .la files will > be needed. > + if [[ "$(file ${ROOT}/bin/bash)" =~ " ELF " ]] > + then > + debug-print "ELF system found, proceeding..." > + ebegin "Removing useless .la files" > + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec > rm -f '{}' '+' > + eend 0 > + else > + debug-print "This appears to be a non-ELF system." > + debug-print "non-ELF systems are likely to need .la files." > + debug-print ".la files not removed from ${TARGET}" > + fi > +} -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-11-09 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-11-09 23h59 UTC. Removals: net-dns/resolvconf-gentoo 2008-11-03 13:04:40 armin76 x11-misc/obpager2008-11-03 23:46:13 darkside x11-themes/lxappearance 2008-11-07 21:26:05 yngwin dev-java/gnu-jaxp 2008-11-09 08:18:46 serkan Additions: dev-ruby/uuidtools 2008-11-03 01:27:39 flameeyes dev-ruby/flickr 2008-11-03 01:38:07 flameeyes gnustep-libs/cddb 2008-11-03 12:08:43 voyageur gnustep-apps/cdplayer 2008-11-03 12:17:17 voyageur sys-block/hpacucli 2008-11-03 16:02:16 wschlich net-misc/aqbanking3-tool2008-11-05 09:04:16 hanno x11-libs/gtkhotkey 2008-11-05 18:24:54 serkan dev-tcltk/tkcon 2008-11-05 21:32:54 bicatali x11-libs/xpa2008-11-05 21:45:11 bicatali sci-astronomy/ast 2008-11-05 22:05:26 bicatali sci-astronomy/funtools 2008-11-05 22:13:59 bicatali lxde-base/lxappearance 2008-11-07 14:28:51 yngwin lxde-base/lxde-common 2008-11-07 14:46:37 yngwin lxde-base/lxlauncher2008-11-07 14:59:32 yngwin lxde-base/lxpanel 2008-11-07 15:07:05 yngwin lxde-base/lxrandr 2008-11-07 15:28:52 yngwin lxde-base/lxsession-lite2008-11-07 15:46:52 yngwin lxde-base/lxtask2008-11-07 15:56:08 yngwin lxde-base/lxterminal2008-11-07 16:10:24 yngwin lxde-base/lxde-meta 2008-11-07 16:33:33 yngwin dev-cpp/pangomm 2008-11-08 22:48:32 eva media-sound/xfi-drivers 2008-11-09 13:32:05 loki_val -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-dns/resolvconf-gentoo,removed,armin76,2008-11-03 13:04:40 x11-misc/obpager,removed,darkside,2008-11-03 23:46:13 x11-themes/lxappearance,removed,yngwin,2008-11-07 21:26:05 dev-java/gnu-jaxp,removed,serkan,2008-11-09 08:18:46 Added Packages: dev-ruby/uuidtools,added,flameeyes,2008-11-03 01:27:39 dev-ruby/flickr,added,flameeyes,2008-11-03 01:38:07 gnustep-libs/cddb,added,voyageur,2008-11-03 12:08:43 gnustep-apps/cdplayer,added,voyageur,2008-11-03 12:17:17 sys-block/hpacucli,added,wschlich,2008-11-03 16:02:16 net-misc/aqbanking3-tool,added,hanno,2008-11-05 09:04:16 x11-libs/gtkhotkey,added,serkan,2008-11-05 18:24:54 dev-tcltk/tkcon,added,bicatali,2008-11-05 21:32:54 x11-libs/xpa,added,bicatali,2008-11-05 21:45:11 sci-astronomy/ast,added,bicatali,2008-11-05 22:05:26 sci-astronomy/funtools,added,bicatali,2008-11-05 22:13:59 lxde-base/lxappearance,added,yngwin,2008-11-07 14:28:51 lxde-base/lxde-common,added,yngwin,2008-11-07 14:46:37 lxde-base/lxlauncher,added,yngwin,2008-11-07 14:59:32 lxde-base/lxpanel,added,yngwin,2008-11-07 15:07:05 lxde-base/lxrandr,added,yngwin,2008-11-07 15:28:52 lxde-base/lxsession-lite,added,yngwin,2008-11-07 15:46:52 lxde-base/lxtask,added,yngwin,2008-11-07 15:56:08 lxde-base/lxterminal,added,yngwin,2008-11-07 16:10:24 lxde-base/lxde-meta,added,yngwin,2008-11-07 16:33:33 dev-cpp/pangomm,added,eva,2008-11-08 22:48:32 media-sound/xfi-drivers,added,loki_val,2008-11-09 13:32:05 Done.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Sunday 09 November 2008, Fabian Groffen wrote: > You could identify ELF a bit more reliable by running file on e.g. > "${ROOT}/bin/bash", or just by building a list of CHOSTs that you > know are ELF systems. D'oh, should have thought of that. See attached patch. > > > > + debug-print "scanelf not found, this appears to be a > > > > non-ELF > > > > system." + debug-print "non-ELF systems are likely to need > > > > .la > > > > files." + debug-print ".la files not removed from > > > > ${TARGET}" > > > > > > rationale? > > > > "I've been told" that .la files are really only needed on non-ELF > > systems and with plugin systems that use dlopen. I actually have no > > way of knowing that the .la files are needed on those arches, but I > > had your archs in mind when doing the patch. > > Ok. What worries me though is that this would result in some systems > having libtool files whereas the majority does not. E.g. removing > them apparently fixes a problem that then crops up on those systems > or something. Can't think of any atm. I can. If you have .la files, you will need to revdep-rebuild a lot more. But c'est la vie. -- /PA --- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200 +++ eutils1.eclass 2008-11-09 18:26:44.0 +0100 @@ -1805,5 +1805,37 @@ ) || die else newbin "${tmpwrapper}" "${wrapper}" || die fi } + +# @FUNCTION: epunt_la_files +# @USAGE: [dir to scan] +# @DESCRIPTION: +# .la files can cause many unpleasantries when they disappear, +# forcing rebuilds of seemingly unrelated packages. +# This function removes the .la files from [dir to scan], "${D}" if not set. +# A good time to start punting .la files may be when a .so bump happens, +# so dependent packages do not have to be rebuilt twice. +# +# See also: +# bug 245889 +# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later + +epunt_la_files() { + debug-print-function $FUNCNAME "$@" + local TARGET=$1 + [ -z "${TARGET}" ] && TARGET="${D}" + + # If this is a non-ELF system, chances are good that the .la files will be needed. + if [[ "$(file ${ROOT}/bin/bash)" =~ " ELF " ]] + then + debug-print "ELF system found, proceeding..." + ebegin "Removing useless .la files" + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+' + eend 0 + else + debug-print "This appears to be a non-ELF system." + debug-print "non-ELF systems are likely to need .la files." + debug-print ".la files not removed from ${TARGET}" + fi +} signature.asc Description: This is a digitally signed message part.