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: | Thu, 22 Sep 2005 10:56:22 | ||

Message-Id: | Pine.LNX.4.63.0509221924240.29467@loopy.telegraphics.com.au |
||

In Reply to: | Re: [gentoo-portage-dev] idea: strict run-time dependencies to remove perl-cleaner, python-updater... by pclouds |

1 | On Thu, 22 Sep 2005, pclouds wrote: |

2 | |

3 | > Well, my aim is mainly perl, python, nautilus, gtk+ modules... As for |

4 | > kernel modules, i'd rather all gentoo-provided kernel modules are |

5 | > updated properly without exaustive search (too slow). |

6 | |

7 | I don't think it would be slow. I say that because it only takes the |

8 | kernel an instant to fail insmod on a incorrectly versioned module, on a |

9 | slow machine (25 MHz). However, it would be slow to rebuild more modules |

10 | than necessary. |

11 | |

12 | Preventing that requires a heuristic that says, "module foo compiled |

13 | against baz-x will not work with new baz-y, where y > x+n". This n is |

14 | often an unknown when a module is emerged, so these rule can't be stated |

15 | in the module ebuild. They have to be stated in the rebuilder that |

16 | ships with baz-y. But preparing those rules would make it more difficult |

17 | to prepare each new kernel release. |

18 | |

19 | I agree that portage could make rebuilders rather easy to write for those |

20 | things where you have a simple rule like "modules built against dep |

21 | version 2.x work with any dep version 2.y". But Linux kernel versioning |

22 | doesn't produce simple rules, and exhaustive searches don't need them. |

23 | |

24 | -f |

25 | |

26 | > People who manually install kernel modules should take care of |

27 | > themselves :) |

28 | > |

29 | > On 9/22/05, Finn Thain <fthain@××××××××××××××××.au> wrote: |

30 | > > |

31 | > > On Wed, 21 Sep 2005, pclouds wrote: |

32 | > > |

33 | > > > This is an idea. |

34 | > > > Everytime you update python, perl to a major version, you have to run |

35 | > > > perl-cleaner/python-updater to re-emerge all packages that depend on |

36 | > > > previous version. The situation is probably similar to kernel |

37 | > > > packages. When you re-compile and install new kernel, you need to |

38 | > > > re-emerge kernel packages to make sure it work properly. I'd rather a |

39 | > > > consistent approach to solve these problems instead seperate updater |

40 | > > > for separate programs such as python-updater, perl-cleaner. |

41 | > > > |

42 | > > > The idea is to use a number to identify compatibility. Those versions |

43 | > > > which have the same number are expected to work well with other |

44 | > > > installed programs. If the number is different, then all other depend |

45 | > > > programs should be re-emerged. |

46 | > > |

47 | > > I assume there is no such thing as a kernel-updater (at least there isn't |

48 | > > one on my system). Your suggestion would make it easier to write one. But, |

49 | > > since kernel symbol versioning is precise enough to detect ABI |

50 | > > compatibility between versions, isn't the problem largely solved in the |

51 | > > kernel? I'm not sure that such a script is needed other than to save you |

52 | > > from having to figure out what pkg contains the module that just broke? |

53 | > > |

54 | > > There is also the problem that some portion of gentoo users roll their own |

55 | > > kernels, without telling portage. |

56 | > > |

57 | > > So, if you wanted to write a kernel-updater, wouldn't it be better to |

58 | > > exhaustively check the module symbols against the Module.symvers file? |

59 | > > (There is also the vermagic field in modinfo, not sure where that comes |

60 | > > from. I'm assuming CONFIG_MODVERSIONS, but those not using that hopefully |

61 | > > know what they are doing anyway :-). |

62 | > > |

63 | > > > When portage merge a package (A) to system, it allow the package to |

64 | > > > specify a number (or string, whatever) to specify a compatibility |

65 | > > > number. When other packages (e.g B) that depend on package A are |

66 | > > > merged, it will keep A's special number in /var/db/pkg. If package A |

67 | > > > is re-emerged and break compatibility, this number should change. |

68 | > > > Otherwise, this number remains the same. |

69 | > > > Those program like perl-cleaner, python-updater may benefit from these |

70 | > > > numbers. It may check for numbers stored in /var/db/pkg's B and number |

71 | > > > in A's. If these numbers differ, B should be re-emerged. |

72 | > > > As for python, all python 2.4's number should be "2.4" and python |

73 | > > > 2.2.x should be "2.2". Perl is similar. As for kernel, the number |

74 | > > > should be timestamp. |

75 | > > |

76 | > > The rebuilder/module ebuilds don't need to know that version x is |

77 | > > compatible with version x+n if the rebuilder is only ever run upon ebuild |

78 | > > advise after an upgrade. |

79 | > > |

80 | > > Consequently, you could just have portage record the actual versions of |

81 | > > the deps that were in use at the time a pkg was emerged (if it doesn't |

82 | > > already?). Then the rebuilder just has to look for any kernel modules that |

83 | > > were emerged while depending on a kernel older than the present one. (I |

84 | > > don't know if this would help with package.provided kernels and |

85 | > > !CONFIG_MODVERSIONS kernels, it might.) |

86 | > > |

87 | > > IMHO an exhaustive search is still the best approach. |

88 | > > |

89 | > > (But don't ask me what you do if the module is not slotted and the |

90 | > > original kernel is still installed as a fall back...) |

91 | > > |

92 | > > -f |

93 | > > |

94 | > > > Suppose i can feed a kernel ebuild with a config file :), then everytime |

95 | > > > i change config, re-emege kernel, compatibility number should change. |

96 | > > > That's the signature for, say, kernel-updater to update all kernel |

97 | > > > packages. |

98 | > > > |

99 | > > > To implement this feature, ebuild should provide a function, say, |

100 | > > > pkg_version() that return compatibility number. Portage should store |

101 | > > > this number in /var/db/pkg. Also, when emerge an ebuild, portage |

102 | > > > should store current compatibility numbers of all direct dependencies. |

103 | > > > The rest of work is left to perl-cleaner, python-updater, |

104 | > > > kernel-updater ..., checking compatibility numbers and update packages |

105 | > > > appropriately. |

106 | > > > |

107 | > > > How about this? |

108 | > > > -- |

109 | > > > Bi Cờ Lao |

110 | > > > |

111 | > > > |

112 | > > |

113 | > |

114 | > |

115 | > -- |

116 | > Bi Cờ Lao |

117 | > |

118 | > |

All times displayed are in UTC (GMT+0).

Contents reflect the opinion of the author, not the Gentoo project or the Gentoo Foundation.

Gentoo is a trademark of the Gentoo Foundation, Inc. The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-4.0 license. The Gentoo Name and Logo Usage Guidelines apply.