[gentoo-dev] [RFC] office-ext.eclass
Hi,
Please see the attached eclass that allows us installation of plugins
for libre(open)office with some easy manner.
Any suggestions and improvements welcome.
Cheers
Tom
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: openoffice.eclass
# @MAINTAINER:
# The openoffice team openoff...@gentoo.org
# @BLURB: Eclass for installing openoffice extensions
# @DESCRIPTION:
# Eclass for easing maitenance of openoffice extensions.
case ${EAPI:-0} in
4) OOEXT_EXPORTED_FUNCTIONS=src_install pkg_postinst pkg_prerm ;;
*) die EAPI=${EAPI} is not supported ;;
esac
EXPORT_FUNCTIONS ${OOEXT_EXPORTED_FUNCTIONS}
inherit eutils multilib
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
# @ECLASS-VARIABLE: OOO_EXTENSIONS
# @REQUIRED
# @DEFAULT_UNSET
# @DESCRIPTION:
# Space separated list of extensions to install.
[[ -z ${OOO_EXTENSIONS} ]] die OOO_EXTENSIONS variable is unset
DEPEND=virtual/ooo
RDEPEND=virtual/ooo
# @FUNCTION: openoffice-ext_flush_unopkg_cache
# @DESCRIPTION:
# Flush the cache after removal of an extension.
openoffice-ext_flush_unopkg_cache() {
debug-print-function ${FUNCNAME} $@
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} list --shared /dev/null
${UNOPKG_BINARY} list --shared /dev/null
}
# @FUNCTION: openoffice-ext_get_implementation
# @DESCRIPTION:
# Determine the implementation we are building against.
openoffice-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=libreoffice openoffice
local i
for i in ${implementations}; do
if [[ -d ${EPREFIX}/usr/$(get_libdir)/${i} ]]; then
debug-print ${FUNCNAME}: Determined implementation is:
\${EPREFIX}/usr/$(get_libdir)/${i}\
echo ${EPREFIX}/usr/$(get_libdir)/${i}
return
fi
done
die Could not determine office implementation!
}
# @FUNCTION: openoffice-ext_add_extension
# @DESCRIPTION:
# Install the extension into the office suite.
openoffice-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} add --shared ${ext}
ebegin Adding extension: \${ext}\
${UNOPKG_BINARY} add --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
rm -rf ${tmpdir}
}
# @FUNCTION: openoffice-ext_remove_extension
# @DESCRIPTION:
# Remove the extension from the office suite.
openoffice-ext_remove_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} remove --shared ${ext}
ebegin Removing extension: \${ext}\
${UNOPKG_BINARY} remove --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
flush_unopkg_cache
rm -rf ${tmpdir}
}
# @FUNCTION: openoffice-ext_src_install
# @DESCRIPTION:
# Install the extension source to the proper location.
openoffice-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
insinto $(openoffice-ext_get_implementation)/share/extension/install/
for i in ${OOO_EXTENSIONS}; do
doins ${i}
done
einfo Remember that if you replace your office implementation,
einfo you need to recompile all the extensions.
einfo Your current implementation location is:
einfo $(openoffice-ext_get_implementation)
}
# @FUNCTION: openoffice-ext_pkg_postinst
# @DESCRIPTION:
# Add the extensions to the libreoffice.
openoffice-ext_pkg_postinst() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OOO_EXTENSIONS}; do
openoffice-ext_add_extension ${i}
done
}
# @FUNCTION: openoffice-ext_pkg_prerm
# @DESCRIPTION:
# Remove the extensions from the libreoffice.
openoffice-ext_pkg_prerm() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OOO_EXTENSIONS} do
openoffice-ext_remove_extension ${i}
done
}
Re: [gentoo-dev] [RFC] office-ext.eclass
Hi Thomas,
Why EAPI=3 is not supported?
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
On my machine unopkg is at '/usr/lib64/libreoffice/program/unopkg'
(libreoffice-bin), so this can be a problem.
Re: [gentoo-dev] [RFC] office-ext.eclass
On Mon, 29 Aug 2011 09:11:31 +0200
Tomáš Chvátal scarab...@gentoo.org wrote:
# @ECLASS: openoffice.eclass
Ekhm.
Also I think, you should use 'openoffice' in the name anyway,
or 'libreoffice', or whatever suggesting the actual office packages
branch.
# @ECLASS-VARIABLE: OOO_EXTENSIONS
# @REQUIRED
# @DEFAULT_UNSET
I don't think you're supposed to mix these two.
openoffice-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=libreoffice openoffice
Be modern, use an array :D.
die Could not determine office implementation!
That sounds weird.
}
openoffice-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
insinto
$(openoffice-ext_get_implementation)/share/extension/install/ for i
in ${OOO_EXTENSIONS}; do doins ${i}
done
I think you should use local scope if you're intending to use 'insinto'.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] office-ext.eclass
Dne 29.8.2011 09:20, Maxim Koltsov napsal(a):
Hi Thomas,
Why EAPI=3 is not supported?
I think we should always use the latest, and this is probably only way
how to force you lads to do so. Also it saves me from having to do
needless || die :)
You have any reason why require eapi3?
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
On my machine unopkg is at '/usr/lib64/libreoffice/program/unopkg'
(libreoffice-bin), so this can be a problem.
Hmpf, easier to do symlinks in the binpkg than to create optional logic
in the eclass, would you mind opening bug for that? (missing unopkg in bin)
Tom
Re: [gentoo-dev] [RFC] office-ext.eclass
Dne 29.8.2011 09:24, Michał Górny napsal(a):
On Mon, 29 Aug 2011 09:11:31 +0200
Tomáš Chvátalscarab...@gentoo.org wrote:
# @ECLASS: openoffice.eclass
Ekhm.
Also I think, you should use 'openoffice' in the name anyway,
or 'libreoffice', or whatever suggesting the actual office packages
branch.
# @ECLASS-VARIABLE: OOO_EXTENSIONS
# @REQUIRED
# @DEFAULT_UNSET
I don't think you're supposed to mix these two.
Why? It make perfect sense, it is both required and empty by default.
openoffice-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=libreoffice openoffice
Be modern, use an array :D.
Sure why not.
die Could not determine office implementation!
That sounds weird.
Why, it returns in the loop above that or thigger this code.
I consider it nicer than adding yet another useless condition.
}
openoffice-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
insinto
$(openoffice-ext_get_implementation)/share/extension/install/ for i
in ${OOO_EXTENSIONS}; do doins ${i}
done
I think you should use local scope if you're intending to use 'insinto'.
What? I really don't get this :)
Updated eclass attached.
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: office-ext.eclass
# @MAINTAINER:
# The office team openoff...@gentoo.org
# @BLURB: Eclass for installing openoffice/libreoffice extensions
# @DESCRIPTION:
# Eclass for easing maitenance of openoffice/libreoffice extensions.
case ${EAPI:-0} in
4) OEXT_EXPORTED_FUNCTIONS=src_install pkg_postinst pkg_prerm ;;
*) die EAPI=${EAPI} is not supported ;;
esac
EXPORT_FUNCTIONS ${OEXT_EXPORTED_FUNCTIONS}
inherit eutils multilib
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
# @ECLASS-VARIABLE: OO_EXTENSIONS
# @REQUIRED
# @DEFAULT_UNSET
# @DESCRIPTION:
# Array containing list of extensions to install.
[[ -z ${OO_EXTENSIONS} ]] die OO_EXTENSIONS variable is unset.
if [[ $(declare -p OO_EXTENSIONS 2/dev/null 21) != declare -a* ]]; then
die OO_EXTENSIONS variable is not an array.
fi
DEPEND=virtual/ooo
RDEPEND=virtual/ooo
# @FUNCTION: openoffice-ext_flush_unopkg_cache
# @DESCRIPTION:
# Flush the cache after removal of an extension.
openoffice-ext_flush_unopkg_cache() {
debug-print-function ${FUNCNAME} $@
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} list --shared /dev/null
${UNOPKG_BINARY} list --shared /dev/null
}
# @FUNCTION: openoffice-ext_get_implementation
# @DESCRIPTION:
# Determine the implementation we are building against.
openoffice-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=(
libreoffice
openoffice
)
local i
for i in ${implementations[$@]}; do
if [[ -d ${EPREFIX}/usr/$(get_libdir)/${i} ]]; then
debug-print ${FUNCNAME}: Determined implementation is:
\${EPREFIX}/usr/$(get_libdir)/${i}\
echo ${EPREFIX}/usr/$(get_libdir)/${i}
return
fi
done
die Unable not determine office implementation!
}
# @FUNCTION: openoffice-ext_add_extension
# @DESCRIPTION:
# Install the extension into the office suite.
openoffice-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} add --shared ${ext}
ebegin Adding extension: \${ext}\
${UNOPKG_BINARY} add --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
rm -rf ${tmpdir}
}
# @FUNCTION: openoffice-ext_remove_extension
# @DESCRIPTION:
# Remove the extension from the office suite.
openoffice-ext_remove_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} remove --shared ${ext}
ebegin Removing extension: \${ext}\
${UNOPKG_BINARY} remove --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
flush_unopkg_cache
rm -rf ${tmpdir}
}
# @FUNCTION: openoffice-ext_src_install
# @DESCRIPTION:
# Install the extension source to the proper location.
openoffice-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
insinto $(openoffice-ext_get_implementation)/share/extension/install/
for i in ${OO_EXTENSIONS[$@]}; do
doins ${i}
done
einfo Remember that if you replace your office implementation,
einfo you need to recompile all the extensions.
einfo Your current implementation
Re: [gentoo-dev] [RFC] office-ext.eclass
# @ECLASS-VARIABLE: OOO_EXTENSIONS # @REQUIRED # @DEFAULT_UNSET I don't think you're supposed to mix these two. Why? It make perfect sense, it is both required and empty by default. Also git-2.eclass use the same and it works.
Re: [gentoo-dev] [RFC] office-ext.eclass
On Mon, 29 Aug 2011 09:39:16 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: # @ECLASS-VARIABLE: OOO_EXTENSIONS # @REQUIRED # @DEFAULT_UNSET I don't think you're supposed to mix these two. Why? It make perfect sense, it is both required and empty by default. It is redundant. If a variable is required to be set, then its default value shouldn't even be set. Look at eclass-to-manpage.awk, @REQUIRED is perfectly enough. die Could not determine office implementation! That sounds weird. Why, it returns in the loop above that or thigger this code. I consider it nicer than adding yet another useless condition. I mean the message text, 'office implementation' :D. KOffice may be an 'office implementation' as well. I think you should use local scope if you're intending to use 'insinto'. What? I really don't get this :) Because caller can have his/her own 'insinto' and yours is going to override that. Look at do* in eutils.eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] office-ext.eclass
2011/8/29 Tomáš Chvátal scarab...@gentoo.org:
Dne 29.8.2011 09:20, Maxim Koltsov napsal(a):
Hi Thomas,
Why EAPI=3 is not supported?
I think we should always use the latest, and this is probably only way how
to force you lads to do so. Also it saves me from having to do needless ||
die :)
You have any reason why require eapi3?
No reason, i just like backaward compability :)
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
On my machine unopkg is at '/usr/lib64/libreoffice/program/unopkg'
(libreoffice-bin), so this can be a problem.
Hmpf, easier to do symlinks in the binpkg than to create optional logic in
the eclass, would you mind opening bug for that? (missing unopkg in bin)
Done, https://bugs.gentoo.org/show_bug.cgi?id=381009
Re: [gentoo-dev] [RFC] office-ext.eclass
How about this attachment? :)
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: office-ext.eclass
# @MAINTAINER:
# The office team openoff...@gentoo.org
# @BLURB: Eclass for installing libreoffice/openoffice extensions
# @DESCRIPTION:
# Eclass for easing maitenance of libreoffice/openoffice extensions.
case ${EAPI:-0} in
4) OEXT_EXPORTED_FUNCTIONS=src_install pkg_postinst pkg_prerm ;;
*) die EAPI=${EAPI} is not supported ;;
esac
EXPORT_FUNCTIONS ${OEXT_EXPORTED_FUNCTIONS}
inherit eutils multilib
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
# @ECLASS-VARIABLE: OO_EXTENSIONS
# @REQUIRED
# @DESCRIPTION:
# Array containing list of extensions to install.
[[ -z ${OO_EXTENSIONS} ]] die OO_EXTENSIONS variable is unset.
if [[ $(declare -p OO_EXTENSIONS 2/dev/null 21) != declare -a* ]]; then
die OO_EXTENSIONS variable is not an array.
fi
DEPEND=virtual/ooo
RDEPEND=virtual/ooo
# @FUNCTION: openoffice-ext_flush_unopkg_cache
# @DESCRIPTION:
# Flush the cache after removal of an extension.
openoffice-ext_flush_unopkg_cache() {
debug-print-function ${FUNCNAME} $@
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} list --shared /dev/null
${UNOPKG_BINARY} list --shared /dev/null
}
# @FUNCTION: openoffice-ext_get_implementation
# @DESCRIPTION:
# Determine the implementation we are building against.
openoffice-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=(
libreoffice
openoffice
)
local i
for i in ${implementations[$@]}; do
if [[ -d ${EPREFIX}/usr/$(get_libdir)/${i} ]]; then
debug-print ${FUNCNAME}: Determined implementation is:
\${EPREFIX}/usr/$(get_libdir)/${i}\
echo ${EPREFIX}/usr/$(get_libdir)/${i}
return
fi
done
die Unable not determine libreoffice/openoffice implementation!
}
# @FUNCTION: openoffice-ext_add_extension
# @DESCRIPTION:
# Install the extension into the office suite.
openoffice-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} add --shared ${ext}
ebegin Adding extension: \${ext}\
${UNOPKG_BINARY} add --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
rm -rf ${tmpdir}
}
# @FUNCTION: openoffice-ext_remove_extension
# @DESCRIPTION:
# Remove the extension from the office suite.
openoffice-ext_remove_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} remove --shared ${ext}
ebegin Removing extension: \${ext}\
${UNOPKG_BINARY} remove --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
flush_unopkg_cache
rm -rf ${tmpdir}
}
# @FUNCTION: openoffice-ext_src_install
# @DESCRIPTION:
# Install the extension source to the proper location.
openoffice-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
(
insinto
$(openoffice-ext_get_implementation)/share/extension/install/
for i in ${OO_EXTENSIONS[$@]}; do
doins ${i}
done
)
einfo Remember that if you replace your office implementation,
einfo you need to recompile all the extensions.
einfo Your current implementation location is:
einfo $(openoffice-ext_get_implementation)
}
# @FUNCTION: openoffice-ext_pkg_postinst
# @DESCRIPTION:
# Add the extensions to the libreoffice.
openoffice-ext_pkg_postinst() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OO_EXTENSIONS[$@]}; do
openoffice-ext_add_extension ${i}
done
}
# @FUNCTION: openoffice-ext_pkg_prerm
# @DESCRIPTION:
# Remove the extensions from the libreoffice.
openoffice-ext_pkg_prerm() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OO_EXTENSIONS[$@]}; do
openoffice-ext_remove_extension ${i}
done
}
Re: [gentoo-dev] [RFC] office-ext.eclass
Dne 29.8.2011 10:24, Maxim Koltsov napsal(a): No reason, i just like backaward compability :) But this is not backcompat this will be completely new and the packages that will be added never were in main tree :-) Done, https://bugs.gentoo.org/show_bug.cgi?id=381009 Thanks
Re: [gentoo-dev] [RFC] office-ext.eclass
2011/8/29 Tomáš Chvátal scarab...@gentoo.org: Dne 29.8.2011 10:24, Maxim Koltsov napsal(a): No reason, i just like backaward compability :) But this is not backcompat this will be completely new and the packages that will be added never were in main tree :-) Oh yes, you're right. I just feel some kind of sadness when old things pass away :) local ext=$1 How about extensions with spaces, if there are any? einfo Remember that if you replace your office implementation, Maybe @ooo-ext-rebuild set would be useful? And you use 'libreoffice' in comments and 'openoffice' in function and variable names. Why?
Re: [gentoo-dev] [RFC] office-ext.eclass
On Mon, 29 Aug 2011 10:35:41 +0200
Tomáš Chvátal scarab...@gentoo.org wrote:
case ${EAPI:-0} in
4) OEXT_EXPORTED_FUNCTIONS=src_install pkg_postinst
pkg_prerm ;; *) die EAPI=${EAPI} is not supported ;;
esac
EXPORT_FUNCTIONS ${OEXT_EXPORTED_FUNCTIONS}
unset OEXT_EXPORTED_FUNCTIONS
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] office-ext.eclass
Dne 29.8.2011 10:57, Maxim Koltsov napsal(a):
2011/8/29 Tomáš Chvátalscarab...@gentoo.org:
Dne 29.8.2011 10:24, Maxim Koltsov napsal(a):
No reason, i just like backaward compability :)
But this is not backcompat this will be completely new and the packages that
will be added never were in main tree :-)
Oh yes, you're right. I just feel some kind of sadness when old things
pass away :)
local ext=$1
How about extensions with spaces, if there are any?
einfo Remember that if you replace your office implementation,
Maybe @ooo-ext-rebuild set would be useful?
And you use 'libreoffice' in comments and 'openoffice' in function and
variable names. Why?
Hopefully updated all. Including Michals comment in other thread.
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: office-ext.eclass
# @MAINTAINER:
# The office team openoff...@gentoo.org
# @BLURB: Eclass for installing libreoffice/openoffice extensions
# @DESCRIPTION:
# Eclass for easing maitenance of libreoffice/openoffice extensions.
case ${EAPI:-0} in
4) OEXT_EXPORTED_FUNCTIONS=src_install pkg_postinst pkg_prerm ;;
*) die EAPI=${EAPI} is not supported ;;
esac
EXPORT_FUNCTIONS ${OEXT_EXPORTED_FUNCTIONS}
unset OEXT_EXPORTED_FUNCTIONS
inherit eutils multilib
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
# @ECLASS-VARIABLE: OO_EXTENSIONS
# @REQUIRED
# @DESCRIPTION:
# Array containing list of extensions to install.
[[ -z ${OO_EXTENSIONS} ]] die OO_EXTENSIONS variable is unset.
if [[ $(declare -p OO_EXTENSIONS 2/dev/null 21) != declare -a* ]]; then
die OO_EXTENSIONS variable is not an array.
fi
DEPEND=virtual/ooo
RDEPEND=virtual/ooo
# @FUNCTION: office-ext_flush_unopkg_cache
# @DESCRIPTION:
# Flush the cache after removal of an extension.
office-ext_flush_unopkg_cache() {
debug-print-function ${FUNCNAME} $@
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} list --shared /dev/null
${UNOPKG_BINARY} list --shared /dev/null
}
# @FUNCTION: office-ext_get_implementation
# @DESCRIPTION:
# Determine the implementation we are building against.
office-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=(
libreoffice
openoffice
)
local i
for i in ${implementations[$@]}; do
if [[ -d ${EPREFIX}/usr/$(get_libdir)/${i} ]]; then
debug-print ${FUNCNAME}: Determined implementation is:
\${EPREFIX}/usr/$(get_libdir)/${i}\
echo ${EPREFIX}/usr/$(get_libdir)/${i}
return
fi
done
die Unable not determine libreoffice/openoffice implementation!
}
# @FUNCTION: office-ext_add_extension
# @DESCRIPTION:
# Install the extension into the libreoffice/openoffice.
office-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$@
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} add --shared ${ext}
ebegin Adding extension: \${ext}\
${UNOPKG_BINARY} add --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
rm -rf ${tmpdir}
}
# @FUNCTION: office-ext_remove_extension
# @DESCRIPTION:
# Remove the extension from the libreoffice/openoffice.
office-ext_remove_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$@
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} remove --shared ${ext}
ebegin Removing extension: \${ext}\
${UNOPKG_BINARY} remove --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
flush_unopkg_cache
rm -rf ${tmpdir}
}
# @FUNCTION: office-ext_src_install
# @DESCRIPTION:
# Install the extension source to the proper location.
office-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
# subshell to not polute rest of the env with the insinto redefinition
(
insinto
$(openoffice-ext_get_implementation)/share/extension/install/
for i in ${OO_EXTENSIONS[$@]}; do
doins ${i}
done
)
einfo Remember that if you replace your office implementation,
einfo you need to recompile all the extensions.
einfo Your current implementation location is:
einfo $(openoffice-ext_get_implementation)
}
# @FUNCTION: office-ext_pkg_postinst
# @DESCRIPTION:
# Add the extensions to the libreoffice/openoffice.
office-ext_pkg_postinst() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OO_EXTENSIONS[$@]}; do
openoffice-ext_add_extension ${i}
Re: [gentoo-dev] net-zope maintenance
On Sun, Aug 14, 2011 at 09:23, Dirkjan Ochtman d...@gentoo.org wrote: Which Zope team is that? Would that be you? Having an overlay with updated packages certainly sounds good, but it would be nice to have some indication of what we're waiting for, or how long we're waiting. Arfrever, it would be nice if you could answer these questions. If there's no answer, we should just go ahead and last-rite the entire category. BTW, what are the mechanics WRT removing an entire category? Should we keep the category around for the benefit of overlays, or are there mechanisms in place so that overlays can setup their own categories? Cheers, Dirkjan
Re: [gentoo-dev] net-zope maintenance
On 08/29/11 13:33, Dirkjan Ochtman wrote: On Sun, Aug 14, 2011 at 09:23, Dirkjan Ochtman d...@gentoo.org wrote: Which Zope team is that? Would that be you? Having an overlay with updated packages certainly sounds good, but it would be nice to have some indication of what we're waiting for, or how long we're waiting. Arfrever, it would be nice if you could answer these questions. If there's no answer, we should just go ahead and last-rite the entire category. BTW, what are the mechanics WRT removing an entire category? Should we keep the category around for the benefit of overlays, or are there mechanisms in place so that overlays can setup their own categories? Overlays can easily define their own categories if needed, so pruning the whole directory should not be a problem. Only profiles/categories might need to be adapted.
Re: [gentoo-dev] [RFC] office-ext.eclass
On 29-08-2011 19:24:24 +, Nathan Phillip Brink wrote:
On Mon, Aug 29, 2011 at 10:35:41AM +0200, Tom Chv??tal wrote:
How about this attachment? :)
# @FUNCTION: openoffice-ext_add_extension
# @DESCRIPTION:
# Install the extension into the office suite.
openoffice-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
Isn't it just as important to doublequote ${T} as it is to doublequote
${D}?
yes
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] Gentoostats, SoC 2011
On 03:18 Fri 26 Aug , Jorge Manuel B. S. Vicetto wrote: I've picked this message as I want to address one point in this thread that was focused on this sub-thread. I disagree with the idea that adding an application to the Gentoo tree that collects data from users and sends it to a central (or distributed) system is the same as adding any other application to the tree. Having the ability to add ebuilds to the tree is part of what you gain by getting gentoo-x86 access. Issues with significant users privacy concerns and substantial changes like adding packages to the tree that collect data from users and compile it, Like, oh, any package with a built-in bug reporting system? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgplaqzIBXO04.pgp Description: PGP signature
Re: [gentoo-dev] Gentoostats, SoC 2011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-08-2011 21:23, Donnie Berkholz wrote: On 03:18 Fri 26 Aug , Jorge Manuel B. S. Vicetto wrote: I've picked this message as I want to address one point in this thread that was focused on this sub-thread. I disagree with the idea that adding an application to the Gentoo tree that collects data from users and sends it to a central (or distributed) system is the same as adding any other application to the tree. Having the ability to add ebuilds to the tree is part of what you gain by getting gentoo-x86 access. Issues with significant users privacy concerns and substantial changes like adding packages to the tree that collect data from users and compile it, Like, oh, any package with a built-in bug reporting system? How many of those are part of the system set or get installed automatically on one's system without any intervention? Furthermore, how many of them are or will be programmed to send data automatically, without prior action of the user and possibly without trace? The point I was addressing is the suggestion that the above should be possible and the idea that any single developer is entitled to do so. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOXEKXAAoJEC8ZTXQF1qEP1ggP+gLBY9IiNjOaIxdQoJ1B/i2f KEmvyTddr4Grxjo8ZME7mefIHi/8ethrWKBuCgf//XshpCQ2r+xKtEgluQf4fX+w MAk9OePybbJJvIeATuoxb/nVYaihMZ7uuOtH5dqbDzhWMMsV0xkmTqgztrQM2v4X jE4yT2hPYV4Ir9OUljzJ5LTBkcdgwDKIjxSn/lUjvCWhNGKr081h6437fOuIQDYE kf+/nDU/UDngk7yKTH4Bgbd7pBNUe8Fu8HJ+7y8iwG0Y4mPW8VCFRHsBFTVNf2/p haX68uC/jPAsWEPO3/YO5rs8JDHNXqL+8zXRPjZn/E0cUkT13+Fa79vKXI6wTPK4 fwF+WZdmAmP/zW5Gs7w82wbML0S0KhQzfVmLu+ne3NBxGhrtnpEzFq6BQgzCtlNu p8vQjtCEVSpeHkTMt0St9/3qPMXhVc1DCRllD2OrEbFil1keHLutDHzIFLVxUZuE 9Fv+esWuTI7yzJjErbvT2OGzbpZMvPuho90QthIbSap/fIf6vK/DOgN+2FcJy0/7 PDtIq8fRL2NF/CQOxjwfGwkpyUK3ZWk7QCBh65MA4PiZHG1eZf5enlvg+WuqYHcC e14tvNVl0FeiW3lwCNy3/IOugSPpIatrbtHCImu0eaJ6oZqLP+OX6HZjpixJg2TP JEnebRBgj6z6VdT774gg =vmrl -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoostats, SoC 2011
On Mon, Aug 29, 2011 at 9:53 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: The point I was addressing is the suggestion that the above should be possible and the idea that any single developer is entitled to do so. It's a moot point, because no one (that I see) claimed or is claiming to be entitled to that. In fact, Alec said We did post to -dev, hence this thread. The point is that we don't need any 'official opinion' to do anything; and I don't want to set that precedent. If you have specific concerns about actions we plan to take (which by the way, we are not planning an opt-out solution. If we plan to do an opt-out solution, we will again have a thread on -dev) then let us know He's not saying that no official opinion would be needed if they were doing an opt-out. He's saying that they don't need an official opinion *since* they aren't doing some sort of opt-out system. Not your fault, but this whole thread regarding the merits/legality/privacy of opt-out is completely irrelevant to the original topic. Matt
