Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

On Thu, Aug 08, 2024 at 08:32:40PM +, Thorsten Glaser wrote: > Helmut Grohne dixit: > >dh_movetousr has nothing to do with protective diversions. It does not > >add nor remove diversions nor does it change any. All it changes is > >locations of files in the data.tar of a .deb. All of the protec

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Helmut Grohne dixit: >> Maybe the protective diversions also protect against this problem as well >> as the problem of moved files? I unfortunately failed to spot where the >> protective diversions were added in dh_movetouser (if that even is the >> right place to be looking), so I'm fairly sure

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Russ Allbery writes: > Sure, no problem. I'll file a bug against dash. #1007263 had already been filed and was on a very similar topic, so I have added some supplemental information to that bug report. -- Russ Allbery (r...@debian.org)

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Helmut Grohne writes: > Such concern is unwarranted. When dpkg unpacks a .deb, it unpacks all > the files with a .dpkg-tmp suffix appended. Hence, we also get a file > /usr/bin/mksh.dpkg-tmp. Once all of these are synced, it issues a > sequence of renames, including rename(/usr/bin/mksh.dpkg-tmp,

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Hi Russ, On Thu, Aug 08, 2024 at 08:40:46AM -0700, Russ Allbery wrote: > Just to be sure, though, I don't think this is the problem that Thorsten > was worried about. My understanding of the problem Thorsten was reporting > was slightly different: Thank you for bridging the gap in communication.

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Thorsten Glaser writes: > There is absolutely no reason to force files to move, given they are now > aliased already *anyway*. I think this is the relevant Policy point. I pretty strongly disagree with this, and I think we also have a consensus on the Policy list that, no, we need to force all

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Helmut Grohne writes: > What changed over time is that we first added diversions for > transitioning from bash to dash and later removed that mechanism as the > transition is complete and the desire to choose your /bin/sh is not as > prevalent as it used to be (mainly because choice of /bin/sh no

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Helmut Grohne writes: > I was looking at this too narrowly from a mksh-perspective only and I > still think that the addition of dh_movetousr to mksh does not worsen > the situation on the mksh side. What I didn't see as clearly earlier is > that the way people tend to use mksh is by adding a loc

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Hi Sam, I see this is getting a bit off-topic and reommend that you spin off a discussion on d-devel if this really matters to you. On Wed, Aug 07, 2024 at 04:27:01PM -0600, Sam Hartman wrote: > > "Helmut" == Helmut Grohne writes: > > Helmut> In bullseye and earlier, I guess it works. >

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

> "Helmut" == Helmut Grohne writes: Helmut> In bullseye and earlier, I guess it works. Helmut> If you start with bullseye or earlier, upgrade to bookworm Helmut> and then to trixie, it continues to work, because the dash Helmut> maintainer scripts preserve any diversion that

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Hi Thorsten, On Wed, Aug 07, 2024 at 09:59:09AM +, Thorsten Glaser wrote: > >that the way people tend to use mksh is by adding a local diversion for > > Unfortunately not. > > The way we have to do it since squeeze, when dash unilaterally broke > cross-package coordination, is: > > dpkg-rec

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

(Another data point is that there’s versions of mksh with version numbers larger than what’s in sid around in my own repo, for those wanting to follow CVS snapshots more closely, backported to all versions up to sarge, so bookworm users can very well have mksh packages with a version number that is

Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Helmut Grohne dixit: >that the way people tend to use mksh is by adding a local diversion for Unfortunately not. The way we have to do it since squeeze, when dash unilaterally broke cross-package coordination, is: dpkg-reconfigure dash ⇒ remove its owning of /bin/sh (so it reverts to bash) ln

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Hi Thorsten and Russ, thanks for dissecting the disagreement. Your reply helped me better understand what Thorsten probably sees as a problem. On Tue, Aug 06, 2024 at 05:23:35PM -0700, Russ Allbery wrote: > Second, you believe the existing migration strategy will not work safely > for mksh becaus

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

(Dropping the pax bug because I think the potential danger to a user's system is specific to mksh because of the /bin/sh symlink.) Thorsten Glaser writes: > If I have a link from /bin/sh to a binary from the mksh package, then on > normal upgrades dpkg updates it atomically. Diverting the binary

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Russ Allbery dixit: >Thorsten Glaser writes: > >> You got your merged /usr already, and to force packages to move their >> files WILL break users’ systems. In particular, mksh as /bin/sh is a >> supported configuration. > >Could you explain how this would break a user's system? From your second

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

Thorsten Glaser writes: > You got your merged /usr already, and to force packages to move their > files WILL break users’ systems. In particular, mksh as /bin/sh is a > supported configuration. Could you explain how this would break a user's system? From your second sentence I'm guessing that y

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Helmut Grohne dixit: >I would like to take the opportunity make you aware of a Debian policy >change #1074014 about merged-/usr. I mentioned your approach in mksh and >pax and the consensus among discussion participants was that policy >should not a