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 |