Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: William Hubbs <williamh@g.o>
Cc: gentoo-dev@l.g.o
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: Fri, 04 Jan 2013 09:39:30
Message-Id: 1357292312.21999.42.camel@belkin4
In Reply to: Re: [gentoo-dev] configuration-doc.eclass: an eclass to install a CONFIGURATION doc file and show an elog message first time package is installed by William Hubbs
1 El jue, 03-01-2013 a las 17:11 -0600, William Hubbs escribió:
2 [...]
3 > >
4 > > But, how to share CONFIGURATION_INSTRUCTIONS contents then for
5 > > create_doc and print_elog? The idea is to share the same message, and
6 > > using global variable for this purpose is already done with
7 > > kernel-2.eclass (I noticed it when doing last tuxonice-sources bumps)
8 >
9 > Does kernel-2.eclass save the message somewhere or just print it? If it
10 > just prints it I can see that, but since you are saving it to a file, I
11 > was just thinking that there is no need to keep a global variable
12 > around.
13 >
14
15 It just print it via elog, but I don't see the difference when it's
16 saved to a file. Anyway, there is no problem on setting it at pkg_setup
17 of src_prepare phases for example.
18
19 [...]
20 >
21 > > > > # @FUNCTION: configuration_print_elog
22 > > > > # @DESCRIPTION:
23 > > > > # Print elog messages with CONFIGURATION_INSTRUCTIONS contents.
24 > > > > # Usually called at pkg_postinst phase.
25 > > > > configuration_print_elog() {
26 > > > > debug-print-function ${FUNCNAME} "${@}"
27 > > > >
28 > > > > if [[ -n "${CONFIGURATION_INSTRUCTIONS}" ]]; then
29 > > >
30 > > > I would recommend using the CONFIGURATION file here, as follows:
31 > > >
32 > > > if [ -f "${T}"/CONFIGURATION ]; then
33 > >
34 > > That is interesting as ensures file was created, but, will it be still
35 > > there at pkg_postinst phase?
36 >
37 > Yes, it should be.
38
39 In that case I will try it, thanks for the tip
40
41 >
42 > > > > if ! [[ "${REPLACING_VERSIONS}" ]]; then
43 > > >
44 > > > This is an issue if I want to add display some tips that have changed
45 > > > between different versions of the software. I would propose not trying
46 > > > to do this, but let the user call this function.
47 > > >
48 > >
49 > > This is intentional because the kind of messages that are always the
50 > > same and, then, need to only be shown with elog first time the package
51 > > is installed need this checking. From packages I have seen, those
52 > > messages that are related with "updating from version XXX" should still
53 > > be handled manually.
54 >
55 > Say I have foobar-1 installed, and it has configuration instructions.
56 > Now, foobar-2 comes along with different configuration instructions
57 > that do not work for foobar-1.
58 > What happens to the CONFIGURATION file when I upgrade? Does it now have
59 > foobar-2's instructions? If not, this is a bug.
60 >
61 > William
62 >
63
64 With current eclass design, you will need to handle it at ebuild itself
65 (as done currently), and handle that way proper version checking that
66 will change depending on each package. Anyway, eclass could be enhanced
67 to also handling this cases but, before that:
68 - we need to agree what is the proper way of using REPLACING_VERSIONS
69 for version checking (some ebuilds use ">/<" operators, while others
70 rely on versionator.eclass)
71 - I need to think how to handle both cases :|
72 - I guess you want to save in CONFIGURATION file that kind of messages
73 version-dependent ONLY when people updates from older versions and,
74 then, once people re-emerge the package, that part will be removed (as
75 is done currently with elog messages that are, for example, behind:
76 if [[ ${REPLACING_VERSIONS} ]] && [[ ${REPLACING_VERSIONS} < XX ]]; then

Attachments

File name MIME type
signature.asc application/pgp-signature