Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 08:31 -0800, Zac Medico escribió:
On 01/17/2013 08:00 AM, Pacho Ramos wrote:
Another try ;)
Looks good to me.
+ 20 Jan 2013; Pacho Ramos pa...@gentoo.org +readme.gentoo.eclass:
+ Finally commit readme.gentoo.eclass to create a README.gentoo doc
file
+ recording tips shown via elog messages first time the package is
merged.
+
About handling more exotic cases (like different tips per version),
please should set DOC_CONTENTS instead of relying in
${FILESDIR}/README.gentoo* files (that are harder to make as flexible as
all this cases would require)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 14-01-2013 a las 01:29 -0800, Zac Medico escribió:
On 01/13/2013 04:59 AM, Pacho Ramos wrote:
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
Here are a few problems I see with readme.gentoo_print_elog:
1) contains duplication of code
2) [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]] condition seems
wrong, shouldn't it just use [[ -f ${T}/README.gentoo ]] since the
file was copied to ${T}/README.gentoo iby readme.gentoo_create_doc?
Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
should be enough, the problem is how to check it :S
3) [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.
Is there a way to check if category/package_name:$SLOT was installed
before merging?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/17/2013 07:17 AM, Pacho Ramos wrote:
El lun, 14-01-2013 a las 01:29 -0800, Zac Medico escribió:
On 01/13/2013 04:59 AM, Pacho Ramos wrote:
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
Here are a few problems I see with readme.gentoo_print_elog:
1) contains duplication of code
2) [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]] condition seems
wrong, shouldn't it just use [[ -f ${T}/README.gentoo ]] since the
file was copied to ${T}/README.gentoo iby readme.gentoo_create_doc?
Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
should be enough, the problem is how to check it :S
3) [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.
Is there a way to check if category/package_name:$SLOT was installed
before merging?
REPLACING_VERSIONS always refers to packages with identical SLOT to the
current package So, if ${REPLACING_VERSIONS} is non-empty, then the
current package replaces another package with identical SLOT.
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 07:47 -0800, Zac Medico escribió:
[...]
Here are a few problems I see with readme.gentoo_print_elog:
1) contains duplication of code
2) [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]] condition seems
wrong, shouldn't it just use [[ -f ${T}/README.gentoo ]] since the
file was copied to ${T}/README.gentoo iby readme.gentoo_create_doc?
Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
should be enough, the problem is how to check it :S
3) [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.
Is there a way to check if category/package_name:$SLOT was installed
before merging?
REPLACING_VERSIONS always refers to packages with identical SLOT to the
current package So, if ${REPLACING_VERSIONS} is non-empty, then the
current package replaces another package with identical SLOT.
Another try ;)
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# look for ${FILESDIR}/README.gentoo contents. You can use
# ${FILESDIR}/README.gentoo-${SLOT} also.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT%/*} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Install generated doc file automatically.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from from just generated doc file.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/17/2013 08:00 AM, Pacho Ramos wrote: Another try ;) Looks good to me. -- Thanks, Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Thu, 17 Jan 2013 07:47:18 -0800 Zac Medico zmed...@gentoo.org wrote: REPLACING_VERSIONS always refers to packages with identical SLOT to the current package No it doesn't. If you have foo-1:a and foo-2:b installed, and then you install foo-1:b, it replaces both 1:a and 2:b. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/01/13 11:00 AM, Pacho Ramos wrote:
Another try ;)
There doesn't seem to be any logic here to check if the README.gentoo
that was previously installed has differed from the one that will be
installed (if they differ then the changes should be shown, no?)
I think logic similar to the following could be added to ensure this
occurs, though:
readme.gentoo_check_update() {
if [[ ${REPLACING_VERSIONS} ]] ; then
if diff -q ${T}/README.gentoo \
${EROOT}/usr/share/doc/${PF}/README.gentoo /dev/null; then
touch ${T}/README.gentoo.show
fi
else
touch ${T}/README.gentoo.show
fi
}
readme.gentoo_pkg_preinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_check_update
}
Then, export the pkg_preinst phase too, and and in
readme.gentoo_print_elog , swap the conditional
! [[ ${REPLACING_VERSIONS} ]] with [[ -e ${T}/README.gentoo.show ]]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF0EAREIAAYFAlD4LKoACgkQ2ugaI38ACPCRvwD/Ub4EBc4ypYgfSItCSXc+ma2C
nrNUySPoHE0Him8vwZkA+LXvVUCNYpwD+DRh/Q5wl5Le8yiDql5F3BuUN0EQU9g=
=JbM2
-END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 11:54 -0500, Ian Stakenvicius escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/01/13 11:00 AM, Pacho Ramos wrote:
Another try ;)
There doesn't seem to be any logic here to check if the README.gentoo
that was previously installed has differed from the one that will be
installed (if they differ then the changes should be shown, no?)
Didn't think in this feature :/
I think logic similar to the following could be added to ensure this
occurs, though:
readme.gentoo_check_update() {
if [[ ${REPLACING_VERSIONS} ]] ; then
if diff -q ${T}/README.gentoo \
${EROOT}/usr/share/doc/${PF}/README.gentoo /dev/null; then
How could we handle different compressors people can use? Depending on
that README.gentoo will change its name ending with gz, bz2, xz... Maybe
we could use README.gentoo*...
touch ${T}/README.gentoo.show
fi
else
touch ${T}/README.gentoo.show
fi
}
readme.gentoo_pkg_preinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_check_update
}
Then, export the pkg_preinst phase too, and and in
readme.gentoo_print_elog , swap the conditional
! [[ ${REPLACING_VERSIONS} ]] with [[ -e ${T}/README.gentoo.show ]]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF0EAREIAAYFAlD4LKoACgkQ2ugaI38ACPCRvwD/Ub4EBc4ypYgfSItCSXc+ma2C
nrNUySPoHE0Him8vwZkA+LXvVUCNYpwD+DRh/Q5wl5Le8yiDql5F3BuUN0EQU9g=
=JbM2
-END PGP SIGNATURE-
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/01/13 12:02 PM, Pacho Ramos wrote: How could we handle different compressors people can use? Depending on that README.gentoo will change its name ending with gz, bz2, xz... Maybe we could use README.gentoo*... Right; I didn't consider how the README.gentoo file might be compressed by dodoc .. OK, more logic required. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD4MM0ACgkQ2ugaI38ACPDbGgD9EpNcrTC7IfDRCUWA2vgVId/t urKESESaRqH3Te6ujXYA/0wLaXOeNQJ8iMylQ4dy4XT5X9JGDB5+bneOM3MyadlM =P6N8 -END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/01/13 11:47 AM, Ciaran McCreesh wrote: On Thu, 17 Jan 2013 07:47:18 -0800 Zac Medico zmed...@gentoo.org wrote: REPLACING_VERSIONS always refers to packages with identical SLOT to the current package No it doesn't. If you have foo-1:a and foo-2:b installed, and then you install foo-1:b, it replaces both 1:a and 2:b. that would be an interesting case with portage, given if foo-1:a moved to foo-1:b that should occur via a slot-move shouldn't it? and therefore would end up conflicting with foo-2:b immediately. This sort of limits said case to something that should never occur ... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD4MX4ACgkQ2ugaI38ACPC2LgEAi70mTJebnH54KiZR2+3BLvCS 5JXl8GDlogEohdqHZ4wA/2+Cs6I4HqAj7SzWbRMPu9u88PyW2Yg2tPyI0Acv/+/A =bFTH -END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 17 Jan 2013 12:14:38 -0500 Ian Stakenvicius a...@gentoo.org wrote: On 17/01/13 11:47 AM, Ciaran McCreesh wrote: On Thu, 17 Jan 2013 07:47:18 -0800 Zac Medico zmed...@gentoo.org wrote: REPLACING_VERSIONS always refers to packages with identical SLOT to the current package No it doesn't. If you have foo-1:a and foo-2:b installed, and then you install foo-1:b, it replaces both 1:a and 2:b. that would be an interesting case with portage, given if foo-1:a moved to foo-1:b that should occur via a slot-move shouldn't it? There's nothing forcing that to be the case. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD4MbkACgkQ96zL6DUtXhEuHgCeJhIsL1d8XofM6RAUCyXwgrPd 3o4AoJpCWOx4SjoMB/O/SfsQ+tl7VBjp =doTo -END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/17/2013 08:47 AM, Ciaran McCreesh wrote: On Thu, 17 Jan 2013 07:47:18 -0800 Zac Medico zmed...@gentoo.org wrote: REPLACING_VERSIONS always refers to packages with identical SLOT to the current package No it doesn't. If you have foo-1:a and foo-2:b installed, and then you install foo-1:b, it replaces both 1:a and 2:b. Ah, that's true, because PMS constraints (and /var/db/pkg layout) force foo-1:b to replace foo-1:a despite the difference in SLOT. For the purposes of readme.gentoo.eclass though, the difference seems negligible (foo-1:a and foo-1:b are likely to have mostly identical README.gentoo content). -- Thanks, Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 12:11 -0500, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/01/13 12:02 PM, Pacho Ramos wrote: How could we handle different compressors people can use? Depending on that README.gentoo will change its name ending with gz, bz2, xz... Maybe we could use README.gentoo*... Right; I didn't consider how the README.gentoo file might be compressed by dodoc .. OK, more logic required. But, since it's compressed diff will always think it's different, then, I am unsure if this could be implemented :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/13/2013 04:59 AM, Pacho Ramos wrote:
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
Here are a few problems I see with readme.gentoo_print_elog:
1) contains duplication of code
2) [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]] condition seems
wrong, shouldn't it just use [[ -f ${T}/README.gentoo ]] since the
file was copied to ${T}/README.gentoo iby readme.gentoo_create_doc?
3) [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 12-01-2013 a las 04:49 -0800, Zac Medico escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2013 02:34 AM, Pacho Ramos wrote:
El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and
gets information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have
different README.gentoo content? Maybe the eclass should
accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from
ebuild and, if not set, rely on common
${FILESDIR}/README.gentoo
You might add a loop to search for a version-specific
README.gentoo, like this:
file= for suffix in -${PV} -${PV}-${PR} ; do [[ -f
${FILESDIR}/README.gentoo${suffix} ]] \
file=${FILESDIR}/README.gentoo${suffix} break done if [[
${file} ]] ; then cp ${file} ${T}/README.gentoo dodoc
${T}/README.gentoo fi
Thank for explaining me how to do that. The problem is that I doubt
if it would really be useful as we usually won't need whan
README.gentoo per version, only to update if for some special cases
from time to time :/
For example: foo-1.0 relies on common README.gentoo file, foo-1.1
adds new feature and, then, would use README.gentoo-1.1 file... but
foo-1.2 will probably use the same README.gentoo-1.1 file :|
Still, it maybe it would be reasonable to use a different
README.gentoo for each SLOT, it there's more than one? Maybe it makes
more sense to have another variable like DOC_CONTENTS, but have it
refer to a filename? Then you should have multiple revisions of an
ebuild refer to the same file, without having to have duplicate
CONTENTS settings.
- --
Thanks,
Zac
What about this approach?
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo-${SLOT} ]]; then
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS}:${SLOT} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
else
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT%/*} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
else
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from ebuild and, if
not set, rely on common ${FILESDIR}/README.gentoo
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from ebuild and, if
not set, rely on common ${FILESDIR}/README.gentoo
You might add a loop to search for a version-specific README.gentoo,
like this:
file=
for suffix in -${PV} -${PV}-${PR} ; do
[[ -f ${FILESDIR}/README.gentoo${suffix} ]] \
file=${FILESDIR}/README.gentoo${suffix} break
done
if [[ ${file} ]] ; then
cp ${file} ${T}/README.gentoo
dodoc ${T}/README.gentoo
fi
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from ebuild and, if
not set, rely on common ${FILESDIR}/README.gentoo
You might add a loop to search for a version-specific README.gentoo,
like this:
file=
for suffix in -${PV} -${PV}-${PR} ; do
[[ -f ${FILESDIR}/README.gentoo${suffix} ]] \
file=${FILESDIR}/README.gentoo${suffix} break
done
if [[ ${file} ]] ; then
cp ${file} ${T}/README.gentoo
dodoc ${T}/README.gentoo
fi
Thank for explaining me how to do that. The problem is that I doubt if
it would really be useful as we usually won't need whan README.gentoo
per version, only to update if for some special cases from time to
time :/
For example: foo-1.0 relies on common README.gentoo file, foo-1.1 adds
new feature and, then, would use README.gentoo-1.1 file... but foo-1.2
will probably use the same README.gentoo-1.1 file :|
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 12-01-2013 a las 11:34 +0100, Pacho Ramos escribió: [...] Thank for explaining me how to do that. The problem is that I doubt if it would really be useful as we usually won't need whan README.gentoo per version, only to update if for some special cases from time to time :/ [...] whan - one :S signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2013 02:34 AM, Pacho Ramos wrote:
El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and
gets information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have
different README.gentoo content? Maybe the eclass should
accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from
ebuild and, if not set, rely on common
${FILESDIR}/README.gentoo
You might add a loop to search for a version-specific
README.gentoo, like this:
file= for suffix in -${PV} -${PV}-${PR} ; do [[ -f
${FILESDIR}/README.gentoo${suffix} ]] \
file=${FILESDIR}/README.gentoo${suffix} break done if [[
${file} ]] ; then cp ${file} ${T}/README.gentoo dodoc
${T}/README.gentoo fi
Thank for explaining me how to do that. The problem is that I doubt
if it would really be useful as we usually won't need whan
README.gentoo per version, only to update if for some special cases
from time to time :/
For example: foo-1.0 relies on common README.gentoo file, foo-1.1
adds new feature and, then, would use README.gentoo-1.1 file... but
foo-1.2 will probably use the same README.gentoo-1.1 file :|
Still, it maybe it would be reasonable to use a different
README.gentoo for each SLOT, it there's more than one? Maybe it makes
more sense to have another variable like DOC_CONTENTS, but have it
refer to a filename? Then you should have multiple revisions of an
ebuild refer to the same file, without having to have duplicate
CONTENTS settings.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlDxW8oACgkQ/ejvha5XGaNc+wCgiaOC7oLLxRvgrGIO9t4SbqTN
Vw8AoIx88SBpcrHAcBO9HhQaCyrtEf3A
=cHLC
-END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 2013-01-12, at 7:49 AM, Zac Medico zmed...@gentoo.org wrote: Still, it maybe it would be reasonable to use a different README.gentoo for each SLOT, it there's more than one? especially since that means no special logic is necessary when cleaning them up on uninstall...
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 07-01-2013 a las 10:34 +0100, Pacho Ramos escribió:
[...]
This will install a README.gentoo file
But there are still pending issues I don't know how to handle:
- Eclass was originally oriented to cover those kind of messages that
could be shown by elog first time the package is merged and, later, rely
on people reading that README.gentoo
- William asked for version checking support, in that case, what kind of
version checking should be covered?
- Should I rely on versionator.eclass or use /? I can see both forms
in the tree right now
- There are also a lot of exotic version checkings in the tree (please
grep looking for REPLACING_VERSIONS to see them) that I doubt we should
cover in eclass but, in that case, how to cover them also?
- A suggestion about looking for ${FILESDIR}/README.gentoo has also
raised, in that case, should eclass look for either option (now
DOC_CONTENTS variable or ${FILESDIR}/README.gentoo)
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
Please take a look to it
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo ]]; then
touch ${T}/README.gentoo.src_install
dodoc ${FILESDIR}/README.gentoo
else
die ${FILESDIR}/README.gentoo doesn't exist!
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with DOC_CONTENTS contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
if [ -f ${T}/README.gentoo.src_install ]; then
cat ${FILESDIR}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
else
die ${T}/README.gentoo.src_install is missing, did you forget to call readme.gentoo_create_doc function?
fi
eshopts_pop
fi
else
die ${FILESDIR}/README.gentoo doesn't exist!
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild,v 1.7
2013/01/03 12:59:15 miska Exp $
EAPI=4
inherit systemd readme.gentoo
DESCRIPTION=Daemon for Advanced Configuration and Power Interface
HOMEPAGE=http://tedfelix.com/linux/acpid-netlink.html;
SRC_URI=http://tedfelix.com/linux/${P}.tar.xz;
LICENSE=GPL-2
SLOT=0
KEYWORDS=amd64 ia64 -ppc x86
IUSE=selinux
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
src_install() {
emake DESTDIR=${D} install
newdoc kacpimon/README README.kacpimon
dodoc -r samples
rm -f ${D}/usr/share/doc/${PF}/COPYING
exeinto /etc/acpi
newexe ${FILESDIR}/${PN}-1.0.6-default.sh default.sh
insinto /etc/acpi/events
newins
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
I would go for versioning it as ${FILESDIR}/README.gentoo-${PV} but,
in that case, I wouldn't know how to make it pick major
README.gentoo-${PV} to prevent people from needing to have one
README.gentoo-${PV} per version :S
Different slots shouldn't need any special handling as their docs should
be installed in their docdir/${PF}
But the anterior variable idea looks to solve this problem much
better :|
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mié, 09-01-2013 a las 22:15 +0100, Pacho Ramos escribió:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
I would go for versioning it as ${FILESDIR}/README.gentoo-${PV} but,
in that case, I wouldn't know how to make it pick major
README.gentoo-${PV} to prevent people from needing to have one
README.gentoo-${PV} per version :S
Different slots shouldn't need any special handling as their docs should
be installed in their docdir/${PF}
But the anterior variable idea looks to solve this problem much
better :|
Maybe the best option would be to:
1. At first look for variable in ebuild
2. If not set, look for ${FILESDIR}/README.gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
Hi,
Quoting Pacho Ramos (2013-01-07 10:34:52)
- Eclass was originally oriented to cover those kind of messages that
could be shown by elog first time the package is merged and, later,
rely on people reading that README.gentoo
This would be good - show README.gentoo for first time, and treat it
with config-protect (as Duncan said somewhere) to be sure user is not
going to miss changes (which could be compared with dispatch-conf).
- William asked for version checking support, in that case, what kind
of version checking should be covered?
- There are also a lot of exotic version checkings in the tree
(please grep looking for REPLACING_VERSIONS to see them) that I doubt
we should cover in eclass but, in that case, how to cover them also?
README.gentoo could have only common info wrt package. Things like
alerts that one should reemerge package because of update (which MUST be
checked with REPLACING_VERSIONS to avoid forcing users to check once
again if he/she is really updating from that version which is pretty
annoying).
- A suggestion about looking for ${FILESDIR}/README.gentoo has also
raised, in that case, should eclass look for either option (now
DOC_CONTENTS variable or ${FILESDIR}/README.gentoo)
${FILESDIR}/README.gentoo seems to be most reasonable place since this
file is going to be installed. Putting it next to metadata.xml and
ChangeLog kills the idea, because of no easy way to see diff.
Regards,
--
Amadeusz Żołnowski
signature.asc
Description: signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2013 11:46 AM, Amadeusz Żołnowski wrote: Hi, Quoting Pacho Ramos (2013-01-07 10:34:52) - Eclass was originally oriented to cover those kind of messages that could be shown by elog first time the package is merged and, later, rely on people reading that README.gentoo This would be good - show README.gentoo for first time, and treat it with config-protect (as Duncan said somewhere) to be sure user is not going to miss changes (which could be compared with dispatch-conf). Maybe something similar to CONFIG_PROTECT is desirable, but it's not exactly the same. The main differences are that the user will always want to accept changes to README.gentoo, and the user will not be interested in trivial formatting changes to README.gentoo. If README.gentoo contained a version number that the package manager could parse, then the package manager could detect when the version number is bumped (indicating a non-trivial change). - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDrc5IACgkQ/ejvha5XGaNPTACg1w1FGrSm+JAG4otnmRT5iIvu DycAoPLCmR8223UH7zzD4HfQ7TiRJWQs =idLH -END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Sun, Jan 6, 2013 at 8:54 PM, Zac Medico zmed...@gentoo.org wrote: On 01/06/2013 05:36 PM, Michael Mol wrote: On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org mailto:zmed...@gentoo.org wrote: On 01/06/2013 01:04 AM, Ralph Sennhauser wrote: On Fri, 4 Jan 2013 23:34:59 -0600 Donnie Berkholz dberkh...@gentoo.org mailto:dberkh...@gentoo.org wrote: On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. See the documentation for README.Debian[1], most importantly the example. ;) I'd say we should handle it the same as Debian does. README.gentoo sounds good to me. What could we possibly gain from doing it differently? Does Debian have a postinst message, like the proposed eclass would generate? Do you agree that a postinst message is desirable feature? [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme -- Thanks, Zac If we had README.gentoo, I'd love it if Portage alerted me as those files changed. Even if it's just whitespace or formatting changes? Maybe it's better to let the ebuild do version comparisons and decide whether to generate a message based on that. I see two solutions to that: 1) Define a format for the file, so that substantive difference can be programmatically discerned from non-substantive differences. I don't have a good proposal for a particular format. 2) Make it so that an author of a README.gentoo file is well aware that any change he makes will potentially annoy all his users if the change isn't substantive. Frankly, (2) seems entirely reasonable. And at the same time, being able to look at version history for README.gentoo files would be extraordinarily enlightening. -- :wq
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/07/2013 05:35 PM, Michael Mol wrote: On Sun, Jan 6, 2013 at 8:54 PM, Zac Medico zmed...@gentoo.org wrote: On 01/06/2013 05:36 PM, Michael Mol wrote: On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org mailto:zmed...@gentoo.org wrote: On 01/06/2013 01:04 AM, Ralph Sennhauser wrote: On Fri, 4 Jan 2013 23:34:59 -0600 Donnie Berkholz dberkh...@gentoo.org mailto:dberkh...@gentoo.org wrote: On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. See the documentation for README.Debian[1], most importantly the example. ;) I'd say we should handle it the same as Debian does. README.gentoo sounds good to me. What could we possibly gain from doing it differently? Does Debian have a postinst message, like the proposed eclass would generate? Do you agree that a postinst message is desirable feature? [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme -- Thanks, Zac If we had README.gentoo, I'd love it if Portage alerted me as those files changed. Even if it's just whitespace or formatting changes? Maybe it's better to let the ebuild do version comparisons and decide whether to generate a message based on that. I see two solutions to that: 1) Define a format for the file, so that substantive difference can be programmatically discerned from non-substantive differences. I don't have a good proposal for a particular format. A version header that the package manager can parse, should do the trick. 2) Make it so that an author of a README.gentoo file is well aware that any change he makes will potentially annoy all his users if the change isn't substantive. Frequent trivial modification should probably be avoided. OTOH, the maintainer should not be ashamed of making occasion small modifications, in order to improve the content quality. Frankly, (2) seems entirely reasonable. And at the same time, being able to look at version history for README.gentoo files would be extraordinarily enlightening. -- :wq -- Thanks, Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/06/2013 01:04 AM, Ralph Sennhauser wrote: On Fri, 4 Jan 2013 23:34:59 -0600 Donnie Berkholz dberkh...@gentoo.org wrote: On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. See the documentation for README.Debian[1], most importantly the example. ;) I'd say we should handle it the same as Debian does. README.gentoo sounds good to me. What could we possibly gain from doing it differently? Does Debian have a postinst message, like the proposed eclass would generate? Do you agree that a postinst message is desirable feature? [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme -- Thanks, Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org wrote: On 01/06/2013 01:04 AM, Ralph Sennhauser wrote: On Fri, 4 Jan 2013 23:34:59 -0600 Donnie Berkholz dberkh...@gentoo.org wrote: On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. See the documentation for README.Debian[1], most importantly the example. ;) I'd say we should handle it the same as Debian does. README.gentoo sounds good to me. What could we possibly gain from doing it differently? Does Debian have a postinst message, like the proposed eclass would generate? Do you agree that a postinst message is desirable feature? [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme -- Thanks, Zac If we had README.gentoo, I'd love it if Portage alerted me as those files changed.
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/06/2013 05:36 PM, Michael Mol wrote: On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org mailto:zmed...@gentoo.org wrote: On 01/06/2013 01:04 AM, Ralph Sennhauser wrote: On Fri, 4 Jan 2013 23:34:59 -0600 Donnie Berkholz dberkh...@gentoo.org mailto:dberkh...@gentoo.org wrote: On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. See the documentation for README.Debian[1], most importantly the example. ;) I'd say we should handle it the same as Debian does. README.gentoo sounds good to me. What could we possibly gain from doing it differently? Does Debian have a postinst message, like the proposed eclass would generate? Do you agree that a postinst message is desirable feature? [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme -- Thanks, Zac If we had README.gentoo, I'd love it if Portage alerted me as those files changed. Even if it's just whitespace or formatting changes? Maybe it's better to let the ebuild do version comparisons and decide whether to generate a message based on that. -- Thanks, Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Fri, Jan 04, 2013 at 11:34:59PM -0600, Donnie Berkholz wrote:
On 10:26 Sat 22 Dec , Pacho Ramos wrote:
Hello
After seeing:
https://bugs.gentoo.org/show_bug.cgi?id=440214
Looking to a lot of its blockers shows that we are using elog messages
for informing people about configuration (like pointing people to
external links to get proper way of configuring things, tell them to add
to some system groups...). I thought that maybe this kind of information
could be simply included in a canonical file under /usr/share/doc/
package dir called, for example, CONFIGURATION or SETUP. We would them
point people (now with a news item, for the long term provably a note to
handbook to newcomers would be nice) to that file to configure their
setups. The main advantages I see:
- We will flood less summary.log ;)
- The information to configure the package is always present while
package is installed, now, if we remove merge produced logs, people will
need to reemerge the package or read directly the ebuild
What do you think?
Bikeshedding ... would go with README.gentoo, because people are already
used to looking for README files. Every time we can eliminate
Gentoo-specific weirdness, we should.
Thinking about this, I tend to agree. That way we can put the README
file in ${FILESDIR} and change it whenever we need to for different
versions of the package.
William
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/
pgpruzYrr009F.pgp
Description: PGP signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgp3sbsAFBIVY.pgp Description: PGP signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
Not that `has_version ${CATEGORY}/${PN}` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:
1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead
Yeah, that is true (and looks like current acpid ebuild is buggy in
this). I wouldn't have any problem on either solution, but using first
one would work in all eapis, is there any reason for printing this kind
of messages in pkg_postinst?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/02/2013 03:48 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
Not that `has_version ${CATEGORY}/${PN}` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:
1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead
Yeah, that is true (and looks like current acpid ebuild is buggy in
this). I wouldn't have any problem on either solution, but using first
one would work in all eapis, is there any reason for printing this kind
of messages in pkg_postinst?
If you need to use pkg_postinst for any reason, you can still call
has_version in pkg_preinst and use a variable to store the result, like
this:
pkg_preinst() {
has_version ${CATEGORY}/${PN}
has_version_result=$?
}
pkg_postinst() {
if [ ${has_version_result} -eq 0 ] ; then
elog ${CONFIGURATION_INSTRUCTIONS}
fi
}
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 31-12-2012 a las 14:53 -0800, Zac Medico escribió:
On 12/31/2012 05:21 AM, Pacho Ramos wrote:
pkg_postinst() {
Some improvements I am not sure how to implement just now:
- What would be the proper way to elog contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:
if ! has_version 'sys-power/acpid'; then
elog
elog You may wish to read the Gentoo Linux Power Management
Guide,
elog which can be found online at:
elog http://www.gentoo.org/doc/en/power-management-guide.xml;
elog
fi
?
Thanks for your help
It seems that you're allowed to call the unpack() function in any phase,
so something like this should work:
cd ${T}
cp ${EROOT}/usr/share/doc/${PF}/CONFIGURATION* ./
[ -f ./CONFIGURATION ] || unpack ./CONFIGURATION*
elog $( ./CONFIGURATION)
Thanks a lot for the tip :)
On the other hand, I have seen another way of doing that looking at
kernel-2.eclass:
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2013-01-01 14:30:18.0 +0100
@@ -17,6 +17,11 @@
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
+CONFIGURATION_INSTRUCTIONS=
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml;
+
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
@@ -37,6 +42,9 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
+ dodoc CONFIGURATION
}
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
[...]
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2013-01-01 14:30:18.0 +0100
@@ -17,6 +17,11 @@
RDEPEND=selinux? ( sec-policy/selinux-apm )
DEPEND=${RDEPEND}
+CONFIGURATION_INSTRUCTIONS=
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml;
+
src_configure() {
econf --docdir=/usr/share/doc/${PF}
}
@@ -37,6 +42,9 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt CONFIGURATION
+ dodoc CONFIGURATION
}
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
Not that `has_version ${CATEGORY}/${PN}` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:
1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El dom, 30-12-2012 a las 00:09 +0100, Pacho Ramos escribió:
[...]
I want to have a permanent reference of current elog messages simply
showing configuration tips to:
1. Show them via elog messages only first time package is installed
2. Not need to read ebuild directly once people remove summary.log
This would be the idea (applied in this example to acpid package)
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.0 +0100
+++ ./acpid-2.0.17.ebuild 2012-12-31 14:18:41.0 +0100
@@ -37,6 +37,13 @@
newconfd ${FILESDIR}/${PN}-2.0.16-conf.d ${PN}
systemd_dounit ${FILESDIR}/systemd/${PN}.{service,socket}
+
+ cat CONFIGURATION -EOF
+ You may wish to read the Gentoo Linux Power Management Guide,
+ which can be found online at:
+ http://www.gentoo.org/doc/en/power-management-guide.xml
+ EOF
+ dodoc CONFIGURATION
}
pkg_postinst() {
Some improvements I am not sure how to implement just now:
- What would be the proper way to elog contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:
if ! has_version 'sys-power/acpid'; then
elog
elog You may wish to read the Gentoo Linux Power Management
Guide,
elog which can be found online at:
elog http://www.gentoo.org/doc/en/power-management-guide.xml;
elog
fi
?
Thanks for your help
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 12/31/2012 05:21 AM, Pacho Ramos wrote:
pkg_postinst() {
Some improvements I am not sure how to implement just now:
- What would be the proper way to elog contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:
if ! has_version 'sys-power/acpid'; then
elog
elog You may wish to read the Gentoo Linux Power Management
Guide,
elog which can be found online at:
elog http://www.gentoo.org/doc/en/power-management-guide.xml;
elog
fi
?
Thanks for your help
It seems that you're allowed to call the unpack() function in any phase,
so something like this should work:
cd ${T}
cp ${EROOT}/usr/share/doc/${PF}/CONFIGURATION* ./
[ -f ./CONFIGURATION ] || unpack ./CONFIGURATION*
elog $( ./CONFIGURATION)
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 24-12-2012 a las 00:30 +0100, Pacho Ramos escribió: El lun, 24-12-2012 a las 00:17 +0100, Diego Elio Pettenò escribió: On 23/12/2012 23:54, Pacho Ramos wrote: The idea would be to make it to be only shown at first message and, later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION file if they want to remember that tip So you want in the main documentation a request to read the package documentation on where to find the upstream documentation? I want to have a permanent reference of current elog messages simply showing configuration tips to: 1. Show them via elog messages only first time package is installed 2. Not need to read ebuild directly once people remove summary.log More examples I saw today when updating: - lm_sensors - shows configuration tips every time it's merged, the idea would be to show it via elog only at first merge and, later, rely on /usr/share/doc file - nvidia-drivers - things like telling people to add them to video group could be treated in the same way, the same probably for eselect instructions. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/12/12 00:09, Pacho Ramos wrote: More examples I saw today when updating: - nvidia-drivers - things like telling people to add them to video group could be treated in the same way, the same probably for eselect instructions. Every game reminds you that you need to be in the games group to play them every time you emerge them. Quite annoying behaviour. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlDfeswACgkQRtClrXBQc7WiZwD9G74WZH58pSyL7Hs2o7Dt6K4Z bMAPA0cGD1/7f6qJviAA/2ErR4bWW/Ma3Zyhkr56YnnbWpgHg84UOPAxwH5oO/yO =4d6G -END PGP SIGNATURE-
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 23 December 2012 09:57, Pacho Ramos pa...@gentoo.org wrote: El sáb, 22-12-2012 a las 13:53 -0800, Zac Medico escribió: On 12/22/2012 01:46 PM, Markos Chandras wrote: On 22 December 2012 09:26, Pacho Ramos pa...@gentoo.org wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Correct me if I am wrong but are you suggesting we drop the elog messages altogether? I still believe that having the elog messages at the end of an 'emerge -uDN world' is more convenient. Maybe it makes sense to have both, as in print the elog messages and create those CONFIGURATION or SETUP files at the same time. As a compromise, you could have the ebuild trigger the elog message only when there is not a previous version of the package installed. That sounds interesting in combination :O Looking to, for example, e4rat ebuild, it should elog the info to configure it first time and later people could rely on CONFIGURATION doc to recover that information, not flooding summary.log any longer and not losing the info, looks nice :D But like I said, elog messages are already saved in /var/log/portage/elog/$cat/$pf so people can read these. Isn't this the same with what you suggest? -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Sun, 2012-12-23 at 12:20 +, Markos Chandras wrote: But like I said, elog messages are already saved in /var/log/portage/elog/$cat/$pf so people can read these. Isn't this the same with what you suggest? Is that by default? And when was that default added? I certainly do not have /var/log/portage/elog/$cat/$pf on my machine (using portage-2.2.0_alpha149), and in fact have never heard of this log file before your email.
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 23 December 2012 13:58, Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Sun, 2012-12-23 at 12:20 +, Markos Chandras wrote: But like I said, elog messages are already saved in /var/log/portage/elog/$cat/$pf so people can read these. Isn't this the same with what you suggest? Is that by default? And when was that default added? I certainly do not have /var/log/portage/elog/$cat/$pf on my machine (using portage-2.2.0_alpha149), and in fact have never heard of this log file before your email. Good question. I believe this is handled by the PORTAGE_ELOG_* variables in /etc/portage/make.conf -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote: On Sun, 2012-12-23 at 12:20 +, Markos Chandras wrote: But like I said, elog messages are already saved in /var/log/portage/elog/$cat/$pf so people can read these. Isn't this the same with what you suggest? Is that by default? And when was that default added? I certainly do not have /var/log/portage/elog/$cat/$pf on my machine (using portage-2.2.0_alpha149), and in fact have never heard of this log file before your email. No, they are not saved there by default. They must be enabled. elog messages are not saved there, those are the build logs. They are saved in /var/log/portage/elog/ as for example: app-portage:gentoolkit-0.3.0.7:20121216-000453.log PLUS, they can be cleaned by emaint or setup to be auto-cleaned by emerge as well so as to not fill up the system with old build logs. emaint -p logs the default is 7 days old, will be cleaned. The emaint log module also takes a -t, --time option. Pacho was right with his original email. It would be best to install that small text file of info where it can be found for reference later. I have often had to go searching ebuilds for elog/einfo data about configuring some pkg for such and such long after it's first install due to needs changing or some breakage of some kind. Much like our gentoo handbook, where most of that info can be found elswhere on the net, this would extend to pkgs so that that info could be compiled together in a place that did not require net access to find key info needed. This proposed method would not apply to all those pkgs with over use of elog/einfo either. Many of those just need to use has_version() to reduce the noise. But there are many such pkgs in the tree that could benefit from the dev putting together a small doc of the configuration info for gentoo, put it into the files dir to be installed as Pacho suggests. It would likely reduce the number of bugs submitted due to bad configuration and make it easier for users to locate (after some time to get use to the idea where to find them). -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 12/23/2012 08:35 AM, Brian Dolbec wrote: On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote: On Sun, 2012-12-23 at 12:20 +, Markos Chandras wrote: But like I said, elog messages are already saved in /var/log/portage/elog/$cat/$pf so people can read these. Isn't this the same with what you suggest? Is that by default? And when was that default added? I certainly do not have /var/log/portage/elog/$cat/$pf on my machine (using portage-2.2.0_alpha149), and in fact have never heard of this log file before your email. No, they are not saved there by default. They must be enabled. /var/log/portage/elog/summary.log is enabled by default though, and portage installs /etc/logrotate.d/elog-save-summary to manage it. -- Thanks, Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El dom, 23-12-2012 a las 13:36 -0800, Zac Medico escribió: On 12/23/2012 08:35 AM, Brian Dolbec wrote: On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote: On Sun, 2012-12-23 at 12:20 +, Markos Chandras wrote: But like I said, elog messages are already saved in /var/log/portage/elog/$cat/$pf so people can read these. Isn't this the same with what you suggest? Is that by default? And when was that default added? I certainly do not have /var/log/portage/elog/$cat/$pf on my machine (using portage-2.2.0_alpha149), and in fact have never heard of this log file before your email. No, they are not saved there by default. They must be enabled. /var/log/portage/elog/summary.log is enabled by default though, and portage installs /etc/logrotate.d/elog-save-summary to manage it. But I remember to, for example, this kind of message: elog elog Please consult the upstream wiki if you need help elog configuring your system elog http://e4rat.sourceforge.net/wiki/index.php/Main_Page; elog The idea would be to make it to be only shown at first message and, later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION file if they want to remember that tip signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 23/12/2012 23:54, Pacho Ramos wrote: The idea would be to make it to be only shown at first message and, later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION file if they want to remember that tip So you want in the main documentation a request to read the package documentation on where to find the upstream documentation? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 24-12-2012 a las 00:17 +0100, Diego Elio Pettenò escribió: On 23/12/2012 23:54, Pacho Ramos wrote: The idea would be to make it to be only shown at first message and, later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION file if they want to remember that tip So you want in the main documentation a request to read the package documentation on where to find the upstream documentation? I want to have a permanent reference of current elog messages simply showing configuration tips to: 1. Show them via elog messages only first time package is installed 2. Not need to read ebuild directly once people remove summary.log signature.asc Description: This is a digitally signed message part
