Gentoo Archives: gentoo-portage-dev

From: Finn Thain <fthain@××××××××××××××××.au>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] idea: strict run-time dependencies to remove perl-cleaner, python-updater...
Date: Wed, 21 Sep 2005 16:03:54
Message-Id: Pine.LNX.4.63.0509220049520.22779@loopy.telegraphics.com.au
In Reply to: [gentoo-portage-dev] idea: strict run-time dependencies to remove perl-cleaner, python-updater... by pclouds
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 >

Replies