From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: pacho@gentoo.org
Subject: Re: [gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed
Date: Thu, 3 Jan 2013 17:11:51 -0600 [thread overview]
Message-ID: <20130103231151.GA29231@linux1> (raw)
In-Reply-To: <1357247001.21999.28.camel@belkin4>
[-- Attachment #1: Type: text/plain, Size: 3780 bytes --]
On Thu, Jan 03, 2013 at 10:03:21PM +0100, Pacho Ramos wrote:
> El jue, 03-01-2013 a las 14:29 -0600, William Hubbs escribió:
> [...]
> > > 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
> >
> > Why does it matter if the unsupported eapi is too old or unknown? I
> > think you can combine the first and last branches of this case
> > statement.
> >
>
> Well, I saw it in other eclasses and thought the distinction was
> preferred, but have no problems on changing it
Well, that's up to you I guess, but, I just didn't see the difference.
> > You can pass in the content as $1 instead of using a global variable for
> > it:
> >
>
> But, how to share CONFIGURATION_INSTRUCTIONS contents then for
> create_doc and print_elog? The idea is to share the same message, and
> using global variable for this purpose is already done with
> kernel-2.eclass (I noticed it when doing last tuxonice-sources bumps)
Does kernel-2.eclass save the message somewhere or just print it? If it
just prints it I can see that, but since you are saving it to a file, I
was just thinking that there is no need to keep a global variable
around.
>
> > > configuration_create_doc() {
> > > debug-print-function ${FUNCNAME} "${@}"
> > >
> > > if [[ -n "${1}" ]]; then
> > > eshopts_push
> > > set -f
> > > echo ${CONFIGURATION_INSTRUCTIONS} | fmt > CONFIGURATION
> >
> > I would use "${T}"/CONFIGURATION here.
> >
> > echo "${1}" | fmt > "${T}"CONFIGURATION
> >
> > > eshopts_pop
> > > dodoc CONFIGURATION
> >
> > Again, "${T}"/CONFIGURATION
> >
>
> I have no problem but, what is its advantage? (to remember it more
> easily next time). Thanks :)
Well, ${T} is a temporary directory where you can put anything you want,
and it is defined in PMS, so I just use it instead of throwing files in
the working tree.
> > > # @FUNCTION: configuration_print_elog
> > > # @DESCRIPTION:
> > > # Print elog messages with CONFIGURATION_INSTRUCTIONS contents.
> > > # Usually called at pkg_postinst phase.
> > > configuration_print_elog() {
> > > debug-print-function ${FUNCNAME} "${@}"
> > >
> > > if [[ -n "${CONFIGURATION_INSTRUCTIONS}" ]]; then
> >
> > I would recommend using the CONFIGURATION file here, as follows:
> >
> > if [ -f "${T}"/CONFIGURATION ]; then
>
> That is interesting as ensures file was created, but, will it be still
> there at pkg_postinst phase?
Yes, it should be.
> > > if ! [[ "${REPLACING_VERSIONS}" ]]; then
> >
> > This is an issue if I want to add display some tips that have changed
> > between different versions of the software. I would propose not trying
> > to do this, but let the user call this function.
> >
>
> This is intentional because the kind of messages that are always the
> same and, then, need to only be shown with elog first time the package
> is installed need this checking. From packages I have seen, those
> messages that are related with "updating from version XXX" should still
> be handled manually.
Say I have foobar-1 installed, and it has configuration instructions.
Now, foobar-2 comes along with different configuration instructions
that do not work for foobar-1.
What happens to the CONFIGURATION file when I upgrade? Does it now have
foobar-2's instructions? If not, this is a bug.
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-01-03 23:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-03 13:01 [gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed Pacho Ramos
2013-01-03 20:29 ` William Hubbs
2013-01-03 21:03 ` Pacho Ramos
2013-01-03 23:11 ` William Hubbs [this message]
2013-01-04 9:38 ` Pacho Ramos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130103231151.GA29231@linux1 \
--to=williamh@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=pacho@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox