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