Don Armstrong <d...@debian.org> writes: > Changing policy without rough consensus would require a CTTE decision on > the matter. Since Russ and Manoj have both laid out their objections to > changing policy by removing the should directive, I don't believe there > is much hope in achieving rough consensus. [Honestly, since 3/3 of the > CTTE members who have commented on this[1] have made their opinion > fairly clear, I'm not sure if there's much hope in that path either.]
For the record, while I supported the original Policy change and am leaning somewhat towards keeping it, I'm not firmly committed to that and could possibly have my mind changed. But I'm not really sure what line of reasoning would do it, or how best to decide. The strongest argument for changing Policy, IMO, is that the name of the binary is an interface and by changing the name of the binary, Debian is changing the interface in a way that invalidates upstream documentation and may require follow-on modifications to other programs. That's a big step to take, and I think there's a reasonable argument that this isn't a step we take necessarily in other places. We have libraries with bad ABIs that we haven't changed because while they're bad, they're not actively broken, and the compatibility is more important than fixing the design problems. Unfortunately, and I'm not sure on which side this argument falls, many of the upstream packages with this problem are generally a mess, and the language extensions aren't the only problem. Often the scripts have far too generic of names, are poorly written in other ways, or do completely bizarre things like the example that just showed up in debian-mentors of a Python program that imported another Python program in /usr/bin as a module. > If scripts are installed into the system PATH, then it's because people > who install those packages are expected to be able to make use of them > as a public API, and they should generally be treated as such. I think this argument cuts both ways: the public API should not hard-code the implementation language, and Debian in general shouldn't change the public API because it creates a lot of work for us and our users. I'm not sure which direction cuts deeper. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org