3 ms·

That is an advantage not a reason it can't be used. Yes alternatives(8) points a symbolic link to a name in the alternatives directory, which means that when y

That is an advantage not a reason it can't be used. Yes alternatives(8) points a symbolic link to a name in the alternatives directory, which means that when you custom package's link to /user/bin/python is overwritten it is trivial to restore. A lot less fragile and resource intensive than using the audit system which the blog post clearly mentions is a bit crusty. Apparmor is another method that is a bit less expensive if it is in use but obviously doesn't work for containers.

nyrikki 4y ago
To expand on the point, /usr still has to support the shared NFS mount model that has mostly been irrelevant for 20 years, the old perl alternatives was partially written to deal with that case. I am pretty sure python2-minimal still triggers update alternatives to support that shared filesystem model. Putting the named links in /etc allows for local configuration and keeps links DAGs
cesarb 4y ago
> Yes alternatives(8) points a symbolic link to a name in the alternatives directory, which means that when you custom package's link to /user/bin/python is overwritten it is trivial to restore. If you use dpkg-divert, it won't be overwritten in the first place. If you install any package which contains a file or symbolic link with that name, that file will instead be written to the name you specified in your dpkg-divert command. It's the correct way (in Debian-derived distributions) to locally override a file or symbolic link which comes from a package which does not use the alternatives mechanism (which is the case for the python-is-python2 and python-is-python3 packages; AFAIK, they contain a plain symbolic link, instead of using update-alternatives).
- nyrikki 4y ago
  I agree that dpkg-divert is a good way also, just that in my experience it is easier to use alternatives for many teams as fpm requires less institutional knowledge. Point being is that at least in my opinion, using the audit system is the hard way especially in a container heavy world and due to the system wide performance impacts of open/close system calls. While there are lots of politics and exceptions with heir(7), those packages should use a link in /usr and not a Host-specific link in a /etc subdirectory. But yes we mostly agree, my problem was with the audit framework which is fragile and expensive.

nyrikki 4y ago

To expand on the point, /usr still has to support the shared NFS mount model that has mostly been irrelevant for 20 years, the old perl alternatives was partially written to deal with that case. I am pretty sure python2-minimal still triggers update alternatives to support that shared filesystem model. Putting the named links in /etc allows for local configuration and keeps links DAGs

cesarb 4y ago

> Yes alternatives(8) points a symbolic link to a name in the alternatives directory, which means that when you custom package's link to /user/bin/python is overwritten it is trivial to restore. If you use dpkg-divert, it won't be overwritten in the first place. If you install any package which contains a file or symbolic link with that name, that file will instead be written to the name you specified in your dpkg-divert command. It's the correct way (in Debian-derived distributions) to locally override a file or symbolic link which comes from a package which does not use the alternatives mechanism (which is the case for the python-is-python2 and python-is-python3 packages; AFAIK, they contain a plain symbolic link, instead of using update-alternatives).

nyrikki 4y ago
I agree that dpkg-divert is a good way also, just that in my experience it is easier to use alternatives for many teams as fpm requires less institutional knowledge. Point being is that at least in my opinion, using the audit system is the hard way especially in a container heavy world and due to the system wide performance impacts of open/close system calls. While there are lots of politics and exceptions with heir(7), those packages should use a link in /usr and not a Host-specific link in a /etc subdirectory. But yes we mostly agree, my problem was with the audit framework which is fragile and expensive.