Helmut Grohne <hel...@subdivi.de> writes:
> 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.
Oh, that's an interesting idea. How about something like:
Since paths either with or without /usr are supported on Debian
systems, maintainers of non-native packages are encouraged to follow
the same conventions as the upstream package when referencing absolute
paths. There is no need to change upstream code from, for example,
/bin to /usr/bin (or from /usr/bin to /bin) when packaging for Debian.
There is a drawback, though: because dpkg only knows about the usr/bin
(etc.) paths, at least as I understand the current state of things, one
cannot find non-/usr paths with dpkg -S. Changing all the paths to
include usr/ therefore does solve a usability issue in some cases, so this
trade off is not entirely obvious.
I have lost track of the work on this. Are there any prospects for dpkg
to know, on Debian systems, that bin/sh and usr/bin/sh are the same thing?
> 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.
My inclination is to say no, we shouldn't allow it in Policy. The release
team can decide whether they care in the case of mksh, and I personally
have a hard time getting that upset about Thorsten carrying that policy
violation in his package when it matters a lot to him and he accepts the
resulting breakage. But I'm fine with calling it a policy violation: it
breaks other tools, making it work is a level of complexity that we don't
need, and it doesn't, so far as I know, have a strong technical
justification.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
