Hi Russ, On Fri, Jun 21, 2024 at 02:06:05PM -0700, Russ Allbery wrote: > I spent some time thinking about this, since I personally still wish > people wouldn't write /usr/bin/sh when they mean /bin/sh. I don't think > Policy should prohibit this since, among other reasons, we have no > effective enforcement mechanism and the package will clearly work fine on > Debian systems. But it would be nice if people didn't gratuitously break > portability, admittedly mostly to non-Linux systems at this point.
I agree with your point of view. Elsewhere, when people asked whether they should move their file references, I argued for "no". I think my wording does not explicitly discourage those changes but makes it clear that they are not required. When we suggested changing the dynamic loader path, there was significant opposition and similarly /usr/bin/sh was not popular. Hence, there is no way of going without those links in the foreseeable future. Is there any way we can further clarify this in the proposed wording? > That said, I think I convinced myself that this is just not something > Policy can reasonably address. We should state the assumption as you > stated it since that's required for packages to use /bin/sh at all, and > this probably is not the place to give people portability advice, > particularly since it only applies to things that might be copied from > Debian to a non-Debian system and most of those aren't under our control > and will never be written to Policy anyway. Portability is one angle and certainly an important one. Spending collective project resources is another one. I argue that changing these paths beyond what is technically necessary is not a good use of our time. So how about having policy recommend not changing path references compared to upstream? I don't think this should be a policy requirement as there may be good reasons to deviate and we can rationalize this recommendation with the portability and the effort arguments. I recognize that it only partially addresses your portability concern as native packages as well as packages where Debian is upstream can freely change those references without violating the recommendation, but those tend to be a minority and a significant portion of them tends to not work on non-Debian systems anyway. > > Questions: I have another question. Thorsten Glaser was unhappy about my mksh report as he believes that it should be /bin/mksh and not /usr/bin/mksh. I argued that the biggest concern is the symlink vs directory conflict and he came up with a crazy solution where mksh's data.tar contains ./bin/mksh but not ./bin on the grounds that ./bin is provided by an essential package in all Debian releases. I think this approach practically solves a significant chunk of the problems listed by DEP17, but it still confuses QA tools and e.g. dpkg -S (maybe more). My proposal here would make mksh's approach violate policy. Should policy allow Thorsten's approach? It certainly is something that needs to be forbidden for any transitively essential package or bootstrapping tools fail. Helmut
