1 |
El jue, 03-01-2013 a las 14:29 -0600, William Hubbs escribió: |
2 |
[...] |
3 |
> > case "${EAPI:-0}" in |
4 |
> > 0|1|2|3) |
5 |
> > die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" |
6 |
> > ;; |
7 |
> > 4|5) |
8 |
> > # EAPI>=4 is required for REPLACING_VERSIONS preventing us |
9 |
> > # from needing to export another pkg_preinst phase to save has_version |
10 |
> > # result. Also relies on EAPI >=4 default src_install phase. |
11 |
> > ;; |
12 |
> > *) |
13 |
> > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" |
14 |
> > ;; |
15 |
> > esac |
16 |
> |
17 |
> Why does it matter if the unsupported eapi is too old or unknown? I |
18 |
> think you can combine the first and last branches of this case |
19 |
> statement. |
20 |
> |
21 |
|
22 |
Well, I saw it in other eclasses and thought the distinction was |
23 |
preferred, but have no problems on changing it |
24 |
|
25 |
> On the other hand, if you don't export phase functions, you don't have |
26 |
> to worry about EAPIS; you can just allow ebuild developers to call your |
27 |
> functions directly. This is what I see happening in your sample ebuild |
28 |
> below. |
29 |
> |
30 |
|
31 |
It exports src_install and pkg_postinst, at least the second one could |
32 |
be used in other ebuilds that are only setting a package specific one |
33 |
for showing this kind of messages (for example bumblebee ebuilds). |
34 |
|
35 |
For src_install case, probably some other ebuilds could benefit, but |
36 |
didn't find them when I fast checked yesterday :/. Its purpose is to |
37 |
ensure doc CONFIGURATION file is created, the ideal would be to be able |
38 |
to only add it to create it and leave other eclasses or eapi defaults to |
39 |
handle the rest of src_install, but I think it's not possible :| (and, |
40 |
then, it will behave like eapi >= 4 default src_install phase + creating |
41 |
the file) |
42 |
|
43 |
|
44 |
Anyway, EAPI >= 4 is still needed for REPLACING_VERSIONS usage, that |
45 |
allows to simplify things preventing us from needing to set pkg_preinst |
46 |
also |
47 |
|
48 |
> > EXPORT_FUNCTIONS src_install pkg_postinst |
49 |
> |
50 |
> Drop this export_functions call. You don't need it based on what I see |
51 |
> in your ebuild. |
52 |
> |
53 |
|
54 |
They can be needed if ebuild doesn't need to have a custom |
55 |
src_install/pkg_postinst only for this purposes |
56 |
|
57 |
> > # @FUNCTION: configuration_create_doc |
58 |
> > # @DESCRIPTION: |
59 |
> > # Create doc file with CONFIGURATION_INSTRUCTIONS contents. |
60 |
> > # Usually called at src_install phase. |
61 |
> |
62 |
> You can pass in the content as $1 instead of using a global variable for |
63 |
> it: |
64 |
> |
65 |
|
66 |
But, how to share CONFIGURATION_INSTRUCTIONS contents then for |
67 |
create_doc and print_elog? The idea is to share the same message, and |
68 |
using global variable for this purpose is already done with |
69 |
kernel-2.eclass (I noticed it when doing last tuxonice-sources bumps) |
70 |
|
71 |
|
72 |
> > configuration_create_doc() { |
73 |
> > debug-print-function ${FUNCNAME} "${@}" |
74 |
> > |
75 |
> > if [[ -n "${1}" ]]; then |
76 |
> > eshopts_push |
77 |
> > set -f |
78 |
> > echo ${CONFIGURATION_INSTRUCTIONS} | fmt > CONFIGURATION |
79 |
> |
80 |
> I would use "${T}"/CONFIGURATION here. |
81 |
> |
82 |
> echo "${1}" | fmt > "${T}"CONFIGURATION |
83 |
> |
84 |
> > eshopts_pop |
85 |
> > dodoc CONFIGURATION |
86 |
> |
87 |
> Again, "${T}"/CONFIGURATION |
88 |
> |
89 |
|
90 |
I have no problem but, what is its advantage? (to remember it more |
91 |
easily next time). Thanks :) |
92 |
|
93 |
> > fi |
94 |
> > } |
95 |
> > |
96 |
> > # @FUNCTION: configuration_print_elog |
97 |
> > # @DESCRIPTION: |
98 |
> > # Print elog messages with CONFIGURATION_INSTRUCTIONS contents. |
99 |
> > # Usually called at pkg_postinst phase. |
100 |
> > configuration_print_elog() { |
101 |
> > debug-print-function ${FUNCNAME} "${@}" |
102 |
> > |
103 |
> > if [[ -n "${CONFIGURATION_INSTRUCTIONS}" ]]; then |
104 |
> |
105 |
> I would recommend using the CONFIGURATION file here, as follows: |
106 |
> |
107 |
> if [ -f "${T}"/CONFIGURATION ]; then |
108 |
|
109 |
That is interesting as ensures file was created, but, will it be still |
110 |
there at pkg_postinst phase? |
111 |
|
112 |
> |
113 |
> > if ! [[ "${REPLACING_VERSIONS}" ]]; then |
114 |
> |
115 |
> This is an issue if I want to add display some tips that have changed |
116 |
> between different versions of the software. I would propose not trying |
117 |
> to do this, but let the user call this function. |
118 |
> |
119 |
|
120 |
This is intentional because the kind of messages that are always the |
121 |
same and, then, need to only be shown with elog first time the package |
122 |
is installed need this checking. From packages I have seen, those |
123 |
messages that are related with "updating from version XXX" should still |
124 |
be handled manually. |
125 |
|
126 |
The eclass could, of course, be handled to also handle this cases, but I |
127 |
would like to keep the "automatic" way of it showing the message only |
128 |
first time package is installed. |
129 |
|
130 |
[...] |
131 |
> > CONFIGURATION_INSTRUCTIONS=" |
132 |
> > You may wish to read the Gentoo Linux Power Management Guide, |
133 |
> > which can be found online at: |
134 |
> > http://www.gentoo.org/doc/en/power-management-guide.xml" |
135 |
> |
136 |
> Delete this and make it a local below if you want the variable, |
137 |
> otherwise pass it as a constant. |
138 |
|
139 |
sorry for the ignorance but, how should I pass it as a constant? Using |
140 |
"readonly"? Also, I am not using here any external tool and, then, |
141 |
global scope shouldn't be discouraged |
142 |
|
143 |
> |
144 |
> > src_configure() { |
145 |
> > econf --docdir=/usr/share/doc/${PF} |
146 |
> > } |
147 |
> > |
148 |
> > src_install() { |
149 |
> > emake DESTDIR="${D}" install |
150 |
> > |
151 |
> > newdoc kacpimon/README README.kacpimon |
152 |
> > dodoc -r samples |
153 |
> > rm -f "${D}"/usr/share/doc/${PF}/COPYING |
154 |
> > |
155 |
> > exeinto /etc/acpi |
156 |
> > newexe "${FILESDIR}"/${PN}-1.0.6-default.sh default.sh |
157 |
> > insinto /etc/acpi/events |
158 |
> > newins "${FILESDIR}"/${PN}-1.0.4-default default |
159 |
> > |
160 |
> > newinitd "${FILESDIR}"/${PN}-2.0.16-init.d ${PN} |
161 |
> > newconfd "${FILESDIR}"/${PN}-2.0.16-conf.d ${PN} |
162 |
> > |
163 |
> > systemd_dounit "${FILESDIR}"/systemd/${PN}.{service,socket} |
164 |
> |
165 |
> local CONFIGURATION_INSTRUCTIONS=" |
166 |
> You may wish to read the Gentoo Linux Power Management Guide, |
167 |
> which can be found online at: |
168 |
> http://www.gentoo.org/doc/en/power-management-guide.xml" |
169 |
> |
170 |
> > configuration_create_doc |
171 |
> |
172 |
> configuration_create_doc "${CONFIGURATION_INSTRUCTIONS}" |
173 |
> > } |
174 |
> > |
175 |
> > pkg_postinst() { |
176 |
> > configuration_print_elog |
177 |
> |
178 |
> The thing that would change here would be that you would have to make |
179 |
> postinst smart enough to know when to call configuration_print_elog. |
180 |
> Maybe you do it all the time like this, or maybe you do it the first |
181 |
> time the package is installed, or you do it when you are upgrading from |
182 |
> an older version and adding or removing some configuration information. |
183 |
> |
184 |
|
185 |
I thought about this but, for now, I preferred to only cover the |
186 |
simplest case for handling messages that are always shown between |
187 |
versions and can be easily standardized. For the other kind of messages, |
188 |
I think it would be much more difficult to standardize but I think could |
189 |
be added later when we start to migrate ebuilds and see the needings. |
190 |
|
191 |
Best regards |