| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 14/01/13 11:36 AM, Zac Medico wrote: |
| 5 |
> On 01/14/2013 08:26 AM, Ian Stakenvicius wrote: |
| 6 |
>> On 14/01/13 10:53 AM, Zac Medico wrote: |
| 7 |
>>> On 01/14/2013 07:44 AM, Zac Medico wrote: |
| 8 |
>>>> On 01/14/2013 07:09 AM, Ian Stakenvicius wrote: |
| 9 |
>>>>> OK i'm a little confused. Putting my earlier note aside, |
| 10 |
>>>>> if the symlink will be auto-cleaned after no packages use |
| 11 |
>>>>> it, what's the point/need for the original message from |
| 12 |
>>>>> portage then?? Is it just QA for the ebuild maintainer? |
| 13 |
>>>> |
| 14 |
>>>> Unfortunately, there are a number of different possible |
| 15 |
>>>> scenarios. It may serve as QA for the ebuild maintainer. It |
| 16 |
>>>> may be triggered by a symlink that the sysadmin has manually |
| 17 |
>>>> created. In any case, there's a performance penalty, since |
| 18 |
>>>> portage has to search for other packages that installed files |
| 19 |
>>>> underneath the symlink. The performance penalty can be |
| 20 |
>>>> avoided for a given symlink by adding it to UNINSTALL_IGNORE |
| 21 |
>>>> (which makes the message useful, regardless of where the |
| 22 |
>>>> symlink originated from). |
| 23 |
>> |
| 24 |
>>> You can measure the performance penalty for the /var/run |
| 25 |
>>> symlink by running this command: |
| 26 |
>> |
| 27 |
>>> time portageq owners / /var/run |
| 28 |
>> |
| 29 |
>> |
| 30 |
>> Based on the performance penalty, would it make sense then for |
| 31 |
>> system-managed symlinks like /var/run that it would be |
| 32 |
>> automatically added to UNINSTALL_IGNORE and its removal managed |
| 33 |
>> separately by whatever put it there in the first place?? |
| 34 |
> |
| 35 |
> There's currently no way for ebuilds to add things to |
| 36 |
> UNINSTALL_IGNORE though (aside from having them edit make.conf). |
| 37 |
> And how is openrc going to know when to remove it? |
| 38 |
|
| 39 |
That would be where some sort of external tracking would need to |
| 40 |
occur, which could be triggered via pkg_postinst and/or |
| 41 |
pkg_{pre,post}rm in the eclass |
| 42 |
|
| 43 |
|
| 44 |
> |
| 45 |
>> (and additionally, that the warning wouldn't be presented to |
| 46 |
>> end-users because of it being a system-managed migration symlink |
| 47 |
>> instead of a end-user-managed one)? |
| 48 |
> |
| 49 |
> Do you want to introduce a new variable for this purpose, and |
| 50 |
> allow ebuilds to modify it via /etc/env.d or something? |
| 51 |
|
| 52 |
Possibly... |
| 53 |
|
| 54 |
For the proof-of-concept phase I'm thinking of doing it via an eclass, |
| 55 |
a file that'd be managed by that eclass, an external tool if required |
| 56 |
to manage said file and/or process removal of the symlink (for cases |
| 57 |
when the symlink isn't put in place by an ebuild during pkg_postinst, |
| 58 |
ie if an init script should clean it up), and either source that file |
| 59 |
or a separate file in make.conf. |
| 60 |
|
| 61 |
At least then we can see if there really is a benefit to changing how |
| 62 |
it is now. I can probably hack an install so that the /var/run |
| 63 |
migration can be redone, for testing.. |
| 64 |
|
| 65 |
-----BEGIN PGP SIGNATURE----- |
| 66 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 67 |
|
| 68 |
iF4EAREIAAYFAlD0OcAACgkQ2ugaI38ACPDkEgD/XYba0NejxqOPv41EsNa8U7tr |
| 69 |
rm4vanPJubJCBX+rsrwA+wUKW3w9nOEkXw87AYJmq0/QFx0vFVfKJLUsrcF168gk |
| 70 |
=imL1 |
| 71 |
-----END PGP SIGNATURE----- |
Archives