1 |
On Wed, 21 Sep 2005, pclouds wrote: |
2 |
|
3 |
> This is an idea. |
4 |
> Everytime you update python, perl to a major version, you have to run |
5 |
> perl-cleaner/python-updater to re-emerge all packages that depend on |
6 |
> previous version. The situation is probably similar to kernel |
7 |
> packages. When you re-compile and install new kernel, you need to |
8 |
> re-emerge kernel packages to make sure it work properly. I'd rather a |
9 |
> consistent approach to solve these problems instead seperate updater |
10 |
> for separate programs such as python-updater, perl-cleaner. |
11 |
> |
12 |
> The idea is to use a number to identify compatibility. Those versions |
13 |
> which have the same number are expected to work well with other |
14 |
> installed programs. If the number is different, then all other depend |
15 |
> programs should be re-emerged. |
16 |
|
17 |
I assume there is no such thing as a kernel-updater (at least there isn't |
18 |
one on my system). Your suggestion would make it easier to write one. But, |
19 |
since kernel symbol versioning is precise enough to detect ABI |
20 |
compatibility between versions, isn't the problem largely solved in the |
21 |
kernel? I'm not sure that such a script is needed other than to save you |
22 |
from having to figure out what pkg contains the module that just broke? |
23 |
|
24 |
There is also the problem that some portion of gentoo users roll their own |
25 |
kernels, without telling portage. |
26 |
|
27 |
So, if you wanted to write a kernel-updater, wouldn't it be better to |
28 |
exhaustively check the module symbols against the Module.symvers file? |
29 |
(There is also the vermagic field in modinfo, not sure where that comes |
30 |
from. I'm assuming CONFIG_MODVERSIONS, but those not using that hopefully |
31 |
know what they are doing anyway :-). |
32 |
|
33 |
> When portage merge a package (A) to system, it allow the package to |
34 |
> specify a number (or string, whatever) to specify a compatibility |
35 |
> number. When other packages (e.g B) that depend on package A are |
36 |
> merged, it will keep A's special number in /var/db/pkg. If package A |
37 |
> is re-emerged and break compatibility, this number should change. |
38 |
> Otherwise, this number remains the same. |
39 |
> Those program like perl-cleaner, python-updater may benefit from these |
40 |
> numbers. It may check for numbers stored in /var/db/pkg's B and number |
41 |
> in A's. If these numbers differ, B should be re-emerged. |
42 |
> As for python, all python 2.4's number should be "2.4" and python |
43 |
> 2.2.x should be "2.2". Perl is similar. As for kernel, the number |
44 |
> should be timestamp. |
45 |
|
46 |
The rebuilder/module ebuilds don't need to know that version x is |
47 |
compatible with version x+n if the rebuilder is only ever run upon ebuild |
48 |
advise after an upgrade. |
49 |
|
50 |
Consequently, you could just have portage record the actual versions of |
51 |
the deps that were in use at the time a pkg was emerged (if it doesn't |
52 |
already?). Then the rebuilder just has to look for any kernel modules that |
53 |
were emerged while depending on a kernel older than the present one. (I |
54 |
don't know if this would help with package.provided kernels and |
55 |
!CONFIG_MODVERSIONS kernels, it might.) |
56 |
|
57 |
IMHO an exhaustive search is still the best approach. |
58 |
|
59 |
(But don't ask me what you do if the module is not slotted and the |
60 |
original kernel is still installed as a fall back...) |
61 |
|
62 |
-f |
63 |
|
64 |
> Suppose i can feed a kernel ebuild with a config file :), then everytime |
65 |
> i change config, re-emege kernel, compatibility number should change. |
66 |
> That's the signature for, say, kernel-updater to update all kernel |
67 |
> packages. |
68 |
> |
69 |
> To implement this feature, ebuild should provide a function, say, |
70 |
> pkg_version() that return compatibility number. Portage should store |
71 |
> this number in /var/db/pkg. Also, when emerge an ebuild, portage |
72 |
> should store current compatibility numbers of all direct dependencies. |
73 |
> The rest of work is left to perl-cleaner, python-updater, |
74 |
> kernel-updater ..., checking compatibility numbers and update packages |
75 |
> appropriately. |
76 |
> |
77 |
> How about this? |
78 |
> -- |
79 |
> Bi Cờ Lao |
80 |
> |
81 |
> |