1 |
On 01/14/2013 07:09 AM, Ian Stakenvicius wrote: |
2 |
> On 14/01/13 09:57 AM, Zac Medico wrote: |
3 |
>> On 01/14/2013 06:46 AM, Ian Stakenvicius wrote: |
4 |
>>> This particular symlink was put there by openrc though, wasn't |
5 |
>>> it? |
6 |
> |
7 |
>> Yeah, openrc uses the migrate_to_run function from |
8 |
>> /etc/init.d/bootmisc. |
9 |
> |
10 |
>>> So I'd expect that on the whole this should be left for openrc to |
11 |
>>> deal with or otherwise left to the user...? |
12 |
> |
13 |
>> As things are now, the symlink is an orphan, and emerge will |
14 |
>> automatically remove the symlink when the last package that |
15 |
>> installed something under /var/run/ is uninstalled. |
16 |
> |
17 |
> ...that doesn't sound good ; /var/run traditionally isn't a path used |
18 |
> solely via src_install() but rather a path used by packages at |
19 |
> runtime, no? If that's the case, that symlink probably should've been |
20 |
> set up to remain until user intervention removes it.. |
21 |
|
22 |
It would be possible would be possible to protect the symlink by having |
23 |
openrc or baselayout install the symlink, so that it's not an orphan. |
24 |
|
25 |
Alternatively, users could manually protect it, by adding this setting |
26 |
to make.conf: |
27 |
|
28 |
UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /var/run" |
29 |
|
30 |
>>> [tangent] it's a bit late for /var/run , but i wonder if, for the |
31 |
>>> next path migration, there might be some way to account for which |
32 |
>>> packages use the old path, say, make a list somewhere, and have |
33 |
>>> the ebuilds remove their atom from that list as they migrate to |
34 |
>>> the new path.. Then once the list is empty the compatibility |
35 |
>>> symlink could be cleaned up automatically or the user notified.. |
36 |
>>> Probably this would need to be handled via an eclass and specific |
37 |
>>> function calls in all relevant ebuilds, as i doubt there would be |
38 |
>>> a way to do this generically in portage itself. [/tangent] |
39 |
>>> |
40 |
> |
41 |
>> That sounds a lot like the existing behavior (automatic symlink |
42 |
>> removal by emerge). |
43 |
> |
44 |
> OK i'm a little confused. Putting my earlier note aside, if the |
45 |
> symlink will be auto-cleaned after no packages use it, what's the |
46 |
> point/need for the original message from portage then?? Is it just QA |
47 |
> for the ebuild maintainer? |
48 |
|
49 |
Unfortunately, there are a number of different possible scenarios. It |
50 |
may serve as QA for the ebuild maintainer. It may be triggered by a |
51 |
symlink that the sysadmin has manually created. In any case, there's a |
52 |
performance penalty, since portage has to search for other packages that |
53 |
installed files underneath the symlink. The performance penalty can be |
54 |
avoided for a given symlink by adding it to UNINSTALL_IGNORE (which |
55 |
makes the message useful, regardless of where the symlink originated from). |
56 |
-- |
57 |
Thanks, |
58 |
Zac |