1 |
On 08/21/11 13:29, Anthony G. Basile wrote: |
2 |
> Hi everyone, |
3 |
> |
4 |
> After updating libraries, I always run something like |
5 |
> |
6 |
> lsof -x / | grep DEL |
7 |
> |
8 |
> to see if any running binaries are linking to old libraries that were |
9 |
> just updated and then I manually restart them. This is particularly |
10 |
> important if the update addresses some security issue in the library. |
11 |
> |
12 |
> Debian and its derivatives take the drastic step of restarting the |
13 |
> daemons for you, which is, in my opinion, undesirable. I'd like to be |
14 |
> in control of when I upgrade and when I restart my daemons. |
15 |
|
16 |
For some users restarting might be acceptable, I would rather not have |
17 |
to figure out why the DB just went down and can't restart during an |
18 |
update :) |
19 |
And the checks (like preserved-libs) that run after pkg installation can |
20 |
take so much time that I'd want them to be user-controllable - sometimes |
21 |
you just don't want to wait 5 minutes after a package merge to regain |
22 |
control of your shell |
23 |
|
24 |
So I think there are three cases we need to consider: |
25 |
1) autorestart. FEATURES-controlled maybe? |
26 |
2) indicator - warn, but do not take any action |
27 |
3) completely disabled, "don't waste my time" |
28 |
> |
29 |
> OpenSuse has a nice solution. After an upgrade, it tells you that there |
30 |
> are some running binaries still linking against the old libraries and |
31 |
> asks you to run "zypper ps" to see them in a pretty format. You can |
32 |
> then restart at your discretion. |
33 |
> |
34 |
> I'm wondering if we should add something like that? Something to be run |
35 |
> post_inst() and just ewarn the user. It could be a small eclass on its |
36 |
> own that maintainers can elect to inherit and use in ebuilds for daemons. |
37 |
|
38 |
eclass sounds hackish since it's portage doing the work. A postinst hook |
39 |
or a direct portage feature sounds more reasonable to me. |
40 |
|
41 |
> What do you think? If its a good idea, is implementing it in an eclass |
42 |
> the way to go? |
43 |
Yes, no :) |
44 |
|
45 |
Have fun, |
46 |
|
47 |
Patrick |