[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters



On Thu, 7 Sept 2023 at 21:22, Helmut Grohne <helmut@subdivi.de> wrote:
>
> Hi Luca,
>
> On Wed, Sep 06, 2023 at 10:50:14PM +0100, Luca Boccassi wrote:
> > Package: debian-policy
> > X-Debbugs-Cc: jak@debian.org helmut@subdivi.de
> >
> > Debian only supports merged-usr since Bookworm. We should update policy
> > to reference /usr/bin/sh and similar paths to describe recommended
> > shebangs for scripts.
>
> I disagree. The promise of merged-/usr has always been that both paths
> are valid. /bin/sh remains the location recommended by external
> standards and (like the dynamic loader path) should remain the way it
> is.
>
> > I heard many times the policy maintainers mention something along the
> > lines of 'policy should not be a hammer to beat other maintainers
> > with'. Today I saw policy being used to force a maintainer to re-add
> > support for the deprecated and unsupported split-usr filesystem layout,
> > as 'policy only mentions /bin/sh, not /usr/bin/sh'.
>
> This can also be addressed by adding a note to policy that allows
> maintainers to rely on the aliasing. If there was a need to refer to the
> shell via /usr/bin/sh, we would aim for eventually removing the aliasing
> symlinks. That's not what we're up to.
>
> > So let's update the policy to refer to modern and supported filesystem
> > paths as adopted by Debian de-facto and de-jure, and stop other
> > maintainers from getting beaten with it.
>
> I don't think this is right. We intend to finalize the /usr-merge
> transition by moving files from / to /usr. This is is an implementation
> strategy that arises from the constraints set by the current
> implementation of dpkg and other components. It is not a new filesystem
> layout that we expect upstreams to support. Rather, we promised to
> upstreams that both ways will work. The aspect that in a data.tar we'll
> have to install files to /usr is a technical one and can be supported by
> debhelper. Still, packages may assume that referencing files they
> installed to /usr via aliased paths in / will continue to work.
>
> > Patch attached and also pushed to
> > https://salsa.debian.org/bluca/policy/-/tree/bin_sh
>
> Nack to this particular change, but I agree that it is worth considering
> two changes to policy sooner and later:
>  * Making it explicit that referring to files via either paths for
>    read-only consumption is ok.
>  * DEP17 aims for not installing any files in aliased locations and we
>    should encode that in policy once there is wide adoption of this rule
>    in binary packages.
>
> Would you agree to repurpose this bug to propose the former change?
> While my variant is weaker, it still prevents people from using policy
> to require supporting split-/usr.

Yes, that is fine by me, as explained in later replies my main
intention is to fix the issue that some wording is being used to
reintroduce things that should not be reintroduced


Reply to: