-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 14/01/13 04:44 AM, Zac Medico wrote:
> On 01/14/2013 01:33 AM, Dirkjan Ochtman wrote:
>> I've seen this pop up a lot recently:
>>
>> * One or more symlinks to directories have been preserved in
>> order to * ensure that files installed via these symlinks remain
>> accessible. This * indicates that the mentioned symlink(s) may be
>> obsolete remnants of an * old install, and it may be appropriate
>> to replace a given symlink with * the directory that it points
>> to. * * /var/run *
>>
>> This might just be me being dense, but this doesn't seem very
>> actionable to me. Who should replace the given symlink with the
>> directory that it points to, the user or the package maintainer?
>
> It depends on who created the symlink in the first place, and
> whether or not the symlink is still desirable. Unfortunately, there
> are a number of possible scenarios.
>
> You probably want to keep that /var/run symlink, at least until all
> of your installed packages have been fixed to use /run directly.
> You can suppress the warning by putting a setting like this in
> make.conf:
>
> UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /var/run"
>
> That will prevent portage from trying to uninstall that symlink.
>
>> And where should it be replaced? In ebuild code?
>
> It's possible for ebuild code to do it, if appropriate for the
> given scenario. For example, the skype ebuild removes an obsolete
> "${EROOT}"/usr/share/${PN} symlink in pkg_preinst.
This particular symlink was put there by openrc though, wasn't it? So
I'd expect that on the whole this should be left for openrc to deal
with or otherwise left to the user...?
[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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlD0GjkACgkQ2ugaI38ACPD5rwD/f4MkzFrlSShRWt/9WB12kybX
uY0uzf5SFmfihzNthOABALr6bT3bB7PAr4eh4tmQH+jH9Z635OD5/BcdJBYw7tLl
=S5ML
-----END PGP SIGNATURE-----
