1 |
On Thu, Jan 03, 2013 at 10:03:21PM +0100, Pacho Ramos wrote: |
2 |
> El jue, 03-01-2013 a las 14:29 -0600, William Hubbs escribió: |
3 |
> [...] |
4 |
> > > case "${EAPI:-0}" in |
5 |
> > > 0|1|2|3) |
6 |
> > > die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" |
7 |
> > > ;; |
8 |
> > > 4|5) |
9 |
> > > # EAPI>=4 is required for REPLACING_VERSIONS preventing us |
10 |
> > > # from needing to export another pkg_preinst phase to save has_version |
11 |
> > > # result. Also relies on EAPI >=4 default src_install phase. |
12 |
> > > ;; |
13 |
> > > *) |
14 |
> > > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" |
15 |
> > > ;; |
16 |
> > > esac |
17 |
> > |
18 |
> > Why does it matter if the unsupported eapi is too old or unknown? I |
19 |
> > think you can combine the first and last branches of this case |
20 |
> > statement. |
21 |
> > |
22 |
> |
23 |
> Well, I saw it in other eclasses and thought the distinction was |
24 |
> preferred, but have no problems on changing it |
25 |
|
26 |
Well, that's up to you I guess, but, I just didn't see the difference. |
27 |
|
28 |
> > You can pass in the content as $1 instead of using a global variable for |
29 |
> > it: |
30 |
> > |
31 |
> |
32 |
> But, how to share CONFIGURATION_INSTRUCTIONS contents then for |
33 |
> create_doc and print_elog? The idea is to share the same message, and |
34 |
> using global variable for this purpose is already done with |
35 |
> kernel-2.eclass (I noticed it when doing last tuxonice-sources bumps) |
36 |
|
37 |
Does kernel-2.eclass save the message somewhere or just print it? If it |
38 |
just prints it I can see that, but since you are saving it to a file, I |
39 |
was just thinking that there is no need to keep a global variable |
40 |
around. |
41 |
|
42 |
> |
43 |
> > > configuration_create_doc() { |
44 |
> > > debug-print-function ${FUNCNAME} "${@}" |
45 |
> > > |
46 |
> > > if [[ -n "${1}" ]]; then |
47 |
> > > eshopts_push |
48 |
> > > set -f |
49 |
> > > echo ${CONFIGURATION_INSTRUCTIONS} | fmt > CONFIGURATION |
50 |
> > |
51 |
> > I would use "${T}"/CONFIGURATION here. |
52 |
> > |
53 |
> > echo "${1}" | fmt > "${T}"CONFIGURATION |
54 |
> > |
55 |
> > > eshopts_pop |
56 |
> > > dodoc CONFIGURATION |
57 |
> > |
58 |
> > Again, "${T}"/CONFIGURATION |
59 |
> > |
60 |
> |
61 |
> I have no problem but, what is its advantage? (to remember it more |
62 |
> easily next time). Thanks :) |
63 |
|
64 |
Well, ${T} is a temporary directory where you can put anything you want, |
65 |
and it is defined in PMS, so I just use it instead of throwing files in |
66 |
the working tree. |
67 |
|
68 |
|
69 |
> > > # @FUNCTION: configuration_print_elog |
70 |
> > > # @DESCRIPTION: |
71 |
> > > # Print elog messages with CONFIGURATION_INSTRUCTIONS contents. |
72 |
> > > # Usually called at pkg_postinst phase. |
73 |
> > > configuration_print_elog() { |
74 |
> > > debug-print-function ${FUNCNAME} "${@}" |
75 |
> > > |
76 |
> > > if [[ -n "${CONFIGURATION_INSTRUCTIONS}" ]]; then |
77 |
> > |
78 |
> > I would recommend using the CONFIGURATION file here, as follows: |
79 |
> > |
80 |
> > if [ -f "${T}"/CONFIGURATION ]; then |
81 |
> |
82 |
> That is interesting as ensures file was created, but, will it be still |
83 |
> there at pkg_postinst phase? |
84 |
|
85 |
Yes, it should be. |
86 |
|
87 |
> > > if ! [[ "${REPLACING_VERSIONS}" ]]; then |
88 |
> > |
89 |
> > This is an issue if I want to add display some tips that have changed |
90 |
> > between different versions of the software. I would propose not trying |
91 |
> > to do this, but let the user call this function. |
92 |
> > |
93 |
> |
94 |
> This is intentional because the kind of messages that are always the |
95 |
> same and, then, need to only be shown with elog first time the package |
96 |
> is installed need this checking. From packages I have seen, those |
97 |
> messages that are related with "updating from version XXX" should still |
98 |
> be handled manually. |
99 |
|
100 |
Say I have foobar-1 installed, and it has configuration instructions. |
101 |
Now, foobar-2 comes along with different configuration instructions |
102 |
that do not work for foobar-1. |
103 |
What happens to the CONFIGURATION file when I upgrade? Does it now have |
104 |
foobar-2's instructions? If not, this is a bug. |
105 |
|
106 |
William |