Hi Ian, On Wed, 2023-08-30 at 12:52 +0100, Ian Jackson wrote: > Debian has historically been simply much more reliable.
Could you quantify this? This is not my experience. As far as I understand you often use non-standard configurations (split-/usr, non-standard init system, ...) which might explain your impression. But non-standard ocnfigurations have been less reliable since forever. > usrmerge is a facet of Debian's culture wars. I would appreciate keeping the discussion to technical parts; could I ask you to keep your concerns about cancel culture elsewhere? > > > This argument is basically drawing together the common Affected > > > tooling includes not just our .debs, but also remote > > > configuration management systems like Ansible, image construction > > > (Dockerfiles), and 3rd-party software installation progrmas > > > (including > > > both 3rd-party .debs and 3rd-party script-based installation > > > systems). > > > > I don't follow the reasoning. [...] > > Sam has posted a helpful set of examples of things that one might do, > whose consequences with aliased directories are unclear. > > These are of course only examples. Tools like Ansible, Dockerfiles, ... have probably already been changed to handle merged-/usr. If they are still horribly broken, please document major issues (there are probably always cases that need a change). I somehow doubt many tools will be broken on many distributions for many years and nobody caring. So please substantiate this claim; it seems wild speculation that tools no longer work on Debian, Ubuntu, Red Hat, SuSE, Arch, Gentoo, ... and that they haven't been changed to work (in so far as this has been neccessary). I see this more as a reason against moving to the proposed Jackson layout with symlink farms: this new layout seems more likely to introduce problems with tooling like Ansible, Docker, ... than an existing layout shared between most(?) larger distributions and already the default for many years. Is there any risk evaluation what happen when moving to symlink farms? > > * Become more precise about what your layout looks like precisely. > > Our > ... > > Let me give some examples to get you started: > > libreoffice -> /bin/python > > ghostscript, imagemagick, mesa -> /bin/env > > bind9, manpages, net-snmp, qtbase-opensource-src -> /bin/perl > > Of these I would hope (by, say, 2033) to only include env. I think "hope" is not a good decision mechanism to produce a high quality operating system. How do you plan to do this? Drop links by throwing a coin, releasing stable, then waiting for user systems to be broken? This has been asked several times, but you refuse to give any answer. > perl upstream doctrine used to be that /usr/bin/perl was the correct > canonical path. I haven't checked if that recommendation still > stands. > > I don't know what Python upstream doctrine is on /bin vs /usr/bin; if > it were that Python is supposed to be in /bin, then we might need to > follow that. (But, are they dropping support for the BSDs?) > > With another hat on in an upstream project I've have been receiving > patches to change #!/bin/bash in CI scripts to #!/usr/bin/env bash. How do you ensure all users follow this scheme required by your proposed symlink farm layout, including for local scripts or scripts taken from systems where they just work? > I think it's worth pointing out that any software which is trying to > be portable to Unix systems other than just Linux (which includes the > BSDs and MacOS) will need to avoid assuming directory aliasing. Which seems irrelevant for what we do in Debian. On portable system you can't assume `/bin/sh` to be there either... Ansgar
