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