1 |
Hi folks, |
2 |
|
3 |
|
4 |
just a little braindump, how revdep-rebuild could be made |
5 |
(partially) obsolete in future: |
6 |
|
7 |
Today it might happen that on an library update an old .so file |
8 |
gets unmerged while still used by somebody - that's what revdep- |
9 |
rebuild scans for. While it should catch those cases, we still |
10 |
have some downtime for certain packages (in bad cases, when it |
11 |
broke somewhere deep in the dependency chain, rebuild might take |
12 |
quite a lot of time). |
13 |
|
14 |
The main problem IMHO is that portage doesn't record which libraries |
15 |
some package links in, so it doesn't know which ones have to be |
16 |
protected from unmerge (unless explicitly stated somewhere). |
17 |
So I'd propose to add record that information. On next merge, |
18 |
this information can be used for an automatic library-protect. |
19 |
This would also record which libraries have been protected from |
20 |
removal and for whom. Subsequent merges will update this that, |
21 |
and once all importers have been unmerged, depclean can clean |
22 |
up the leftover dirt. |
23 |
|
24 |
|
25 |
What do you think about this idea ? |
26 |
|
27 |
|
28 |
cu |
29 |
-- |
30 |
---------------------------------------------------------------------- |
31 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
32 |
|
33 |
phone: +49 36207 519931 email: weigelt@×××××.de |
34 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
35 |
---------------------------------------------------------------------- |
36 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
37 |
---------------------------------------------------------------------- |