XPost: linux.debian.bugs.dist, linux.debian.devel
From: [email protected]

Package: tech-ctte
X-Debbugs-Cc: Russ Allbery <[email protected]>, Sean Whitton <[email protected]>, Helmut Grohne <[email protected]>, Luca Boccassi <[email protected]>, [email protected], [email protected]

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:

Ansgar <[email protected]> writes:

Debian going out of its way to tell derivative users to switch back from merged-/usr to split-/usr is the *opposite* of trying to make things as smooth for them as possible.

Yes, I agree with that part and I think I objected to that at the time. Nonetheless, one bad decision doesn't mean that it is Debian policy that
we don't care about derivatives or their users.  I think we made a mistake there which is not in alignment with our ideals or our goals.  We should
try to reverse that mistake, not double down on it.

Cool, then let's ask tech-ctte.

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Thanks,
Ansgar

[1]: https://bugs.debian.org/994388#397

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

Hi Sean,

On 11/05/2023 03:59, Sean Whitton wrote:

Hello,

On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Currently dpkg contains code to emit the merged-/usr warning, that's
dead code on Debian, but which becomes active when packages from the
Debian archive are copied unmodified into derivatives.

The heart of the issue is how dpkg is a native package. What we're
talking about is not the Debian system, but the Debian archive as it
exists independently of the Debian system.

dpkg has an upstream existence that's independent of Debian, and it's perfectly legitimate for that version of dpkg to emit the warning. The problem here might be caused by how the Debian archive is implicitly
being used to distribute upstream dpkg.

This is not in itself a problem -- we distribute a lot of stuff in
source packages that does not form part of the Debian system. But in
this case, this distribution that's occurring might conflict with how
Debian is seeking to provide a product not just to end users, but also
to those building derivatives.

One simple solution is for dpkg to become a non-native package, carrying Debian-specific patches to do things like remove the warning code.

I think you're conflating two independent things.

If you override the dpkg maintainer to remove that warning that occurs on derivatives, then anyone could NMU dpkg and the maintainer wouldn't introduce it
back, effectively removing the warning from "dpkg upstream".

OTOH if the dpkg maintainer switches to non-native packages, anyone could NMU it
adding the change as a patch, however the maintainer will just NACK the NMU before or after it happens.

So I don't see a problem with dpkg being native, just like e.g. apt is, and that
won't magically solve the issue at hand.

Cheers,
Emilio

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

Hi,

On 5/11/23 10:59, Sean Whitton wrote:

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Currently dpkg contains code to emit the merged-/usr warning, that's
dead code on Debian, but which becomes active when packages from the
Debian archive are copied unmodified into derivatives.

The way I see it (but I'm not a dpkg maintainer), the current
implementation is correct, as dpkg does not support aliased directories,
but Debian has decided to use it in such an environment nonetheless. The tech-ctte decision not to roll back usrmerge accepts responsibility for
this decision, so silencing the warning on Debian is correct, but no one
has accepted that responsibility for derived distributions.

Any derived distribution can easily go on record and request inclusion
in the list of distributions where this warning is suppressed, by typing
the phrase "Yes, I understand that this is a bad idea." into an email
client.

dpkg has an upstream existence that's independent of Debian, and it's perfectly legitimate for that version of dpkg to emit the warning. The problem here might be caused by how the Debian archive is implicitly
being used to distribute upstream dpkg.

I'm skeptical about splitting development and packaging, though,
especially in this context, because we'd need to clarify how far we'd
want upstream dpkg and Debian dpkg to deviate.

Basically, non-native dpkg has two scenarios: either it is maintained by
the same people as now, which causes them extra work for no clear
benefit, or we find maintainers willing to deal with complex bug reports
that upstream is fully entitled to reject because Debian brought this
onto themselves by deciding that one upstream project's "unsupported configuration" needs to be avoided by moving to another upstream
project's "unsupported configuration."

Those same people who would volunteer to maintain such a package could
spend their energy finding a solution that can be merged into "upstream"
dpkg, that would be more productive.

Simon

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

On Thu, 11 May 2023 21:16:34 +0900 Simon Richter <[email protected]>
wrote:

Hi,

On 5/11/23 10:59, Sean Whitton wrote:

Dear ctte, please consider overruling the dpkg maintainer to

include

the patch from #994388[1].

Currently dpkg contains code to emit the merged-/usr warning,

that's

dead code on Debian, but which becomes active when packages from

the

Debian archive are copied unmodified into derivatives.

The way I see it (but I'm not a dpkg maintainer), the current
implementation is correct, as dpkg does not support aliased

directories,

but Debian has decided to use it in such an environment nonetheless.

The

tech-ctte decision not to roll back usrmerge accepts responsibility

for

this decision, so silencing the warning on Debian is correct, but no

one

has accepted that responsibility for derived distributions.

Any derived distribution can easily go on record and request

inclusion

in the list of distributions where this warning is suppressed, by

typing

the phrase "Yes, I understand that this is a bad idea." into an email
client.

The crux of the issue is that we are hearing how negatively affecting derivatives in any way, even purely theoretically, is a big no-no, in
this very same thread and topic. Reaching out and asking for directions/help/whatever is not enough in that context. So it follows
that it cannot be enough in this context either, and it must be fixed
instead.

Or alternatively, we can establish that a documentation/post-facto
approach is enough for derivatives, and then that's valid for all
changes and transitions.

Either of these are valid approaches.

What I cannot find acceptable is that some changes get a free pass, and
some get roadblocks after roadblocks thrown at them.

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmRdKysACgkQKGv37813 JB4p7w/7BN2x6JSkbUuhhsYb7HRHzrIsNCvVaGMpam40/MywtWpsP6c6JhFA/bcZ ur0RNEQQEflSuxrv7TgxPrQLeSOqe4eYgdszgsz/iBxZH/1E47afmqD74lngRDuS n6znjPnWC6uMFYXs93yjVaJqJ0oAssdw6oIl5JlepOAvePPy2xwmXPPkH1lFFQx/ eQXHwiQ/EvpRwFXeJTfMGKj7wHm/ofbkGjXiwMQ0wJyXoW773jODRf1qWvkvAVt8 WhVrmDAkCz0+wVIP6maUhZTvNiWAPxQkNHfhipVLzFn89Q/B0SLex15AVd3xt3gA jT1yItxSSjvABN7FMNGErOUbr0t8qgesmNI+4IxaJ97+UqLoWiIATI9afgNs+iam 09z3rh9eaXYgXBIsYuu7Uiz+QsJHaimUhNlaXLW+FX9FrZycifjTawKVXZzx4Xdr SFErX/BCnxVVxaBjEuDOPoazzoPNeOZ6+hHVwZPq51Rx8rUVWLf/fEt+eNECfhGs /lGFhsK+P047f1Df1Pvq3f5Z1MyzfhCj6Uz4l5cBs5B85NHQGtb+SaRV6L1YFlNv GvynmtgFY+CxJ1H2a3okgKl+aXMSl03xf0l7STuIf7+4/0Ii5Njd2pIvXRH/t2dT 4/JWhzOcwRFqo8UGatpU1RO3cWWVQh3LBzf78MwFCt6Bvt8GDw8=
=CjRt
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

Hi,

On 5/12/23 02:51, Luca Boccassi wrote:

Or alternatively, we can establish that a documentation/post-facto
approach is enough for derivatives, and then that's valid for all
changes and transitions.

For the context of this bug, the notice *is* the after-the-fact
documentation of an interface change, i.e. the bare minimum.

It would have been better to get input from derived distributions about
this interface change before it happened, but given that the interface
change was not caused by a change in dpkg code, but by the introduction
of the usrmerge package, there was not much of a remedy available then.

Simon

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

On Fri, 12 May 2023 at 13:21, Simon Richter <[email protected]> wrote:

Hi,

On 5/12/23 02:51, Luca Boccassi wrote:

Or alternatively, we can establish that a documentation/post-facto
approach is enough for derivatives, and then that's valid for all
changes and transitions.

For the context of this bug, the notice *is* the after-the-fact
documentation of an interface change, i.e. the bare minimum.

It would have been better to get input from derived distributions about
this interface change before it happened, but given that the interface
change was not caused by a change in dpkg code, but by the introduction
of the usrmerge package, there was not much of a remedy available then.

Not really? This notice is new, and suggests something that will make
the downstream irreparably incompatible with Debian, which I thought
was a big no-no.
If negatively affecting downstreams is a problem, this needs to be
reverted. If it's enough to say somewhere else "actually, that is bad
advice, if you follow it you are on your own", then that's fine too by
me, but then it's fine for other changes as well.

Kind regards,
Luca Boccassi

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

Hi Ansgar,

I'm speaking with a CTTE hat here, but not representing CTTE consensus.

On Wed, May 10, 2023 at 11:47:42PM +0200, Ansgar wrote:

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

I think we need to reject this request on multiple levels.

On a social level, I see that you are frustrated with how dpkg is being maintained and how communication does not work out in practice. While
part of that can be attributed to the dpkg maintainer, this goes both
ways and the way you refer this matter to the CTTE without even
attempting to resolve it by other means just serves to deepen that
dispute. I see that the dpkg maintainer has recently contributed
constructively to the discussion about how dpkg can be part of a
solution for the problems resulting from the /usr merge. I have a hard
time saying the same about your interaction here. Therefore, I think
your request should be rejected as not being serious.

On a process level, I think I miss attempts to resolve this with the
dpkg maintainer in a constructive way. The present discussion clearly
shows that dpkg's support for how Debian deals with merged /usr is
lacking. We are dealing with multiple file-loss scenarios (something we otherwise consider grave) and issuing a warning about such behaviour
seems fine to me. On the other hand, much of the project seems to agree
that the way this warning is worded is far from optimal and evidently
leads to confused users. And while it may seem that any attempt at
resolving may lead nowhere, the same can be said about our dpkg
maintainer's concerns about our /usr-merge strategy and him pointing out
real problems affecting Debian installations in practice. Given the
recent constructive communication, I think it is far from clear that
this option is exhausted. In particular, acknowledging the problems
presented and proposing strategies for dealing with them could go a long
way towards a cooperative solution. At present, I see the options to
keep and to delete the warning on the table, but there clearly is
unexplored middle ground. As such, I think your request should be
rejected as not having exhausted the solution space.

On a technical level, Debian's support for merged /usr is currently
founded on the moratorium preventing breakage. Please observe that this moratorium applies to Debian and Debian only. We have implemented
processes to validate this. If a derivative wants to use merged /usr
(which probably every derivative should), it certainly needs to prevent breakage in some way - presumably using a similar process. I think that
the cost of patching dpkg is minor compared to the cost of a process
that prevents breakage arising from our merged /usr strategy. Given
this, a warning-by-default (worded in a better way) for derivatives
actually can be a good thing, because it makes derivatives aware that
they cannot just ignore merged /usr, but have to act. As such, I think
your request should be rejected since the measure is technically
reasonable in principle.

Does anyone mind just closing the bug?

At the same time, I recommend changing the warning. The amount of
feedback we get regarding the warning should make it clear that the
current wording is still seen as offensive and causes confusion. Keeping
the warning in its current form also serves little but deepening the
dispute.

For instance, the wording "going behind dpkg's back" may be considered technically correct, but it also can be objectively described as passive aggressive. Just deleting this aspect and instead saying "This system
uses merged-usr-via-aliased-dirs which violates core assumptions of
dpkg." would probably keep the intended message in a less
confrontational way. Elaborating that file loss is being mitigated by a process (moratorium) on Debian would also help. Looking into the wiki, a recommendation of dpkg-fsys-usrunmess should caution that using it now
breaks other tool's assumptions such as systemd and is generally not
being tested with QA anymore.

Even if one were thinking that the warning were appropriate as is,
adapting it again due to community feedback would demonstrate empathy
and be a step towards a cooperative solution.

I think our priority should be finding a way to terminate the
moratorium.

Helmut

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

Hi,

This thread has rather veered off the initial bug report.

On 11/05/2023 13:16, Simon Richter wrote:

Hi,

On 5/11/23 10:59, Sean Whitton wrote:

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Currently dpkg contains code to emit the merged-/usr warning, that's
dead code on Debian, but which becomes active when packages from the
Debian archive are copied unmodified into derivatives.

The way I see it (but I'm not a dpkg maintainer), the current
implementation is correct, as dpkg does not support aliased directories,
but Debian has decided to use it in such an environment nonetheless. The tech-ctte decision not to roll back usrmerge accepts responsibility for
this decision, so silencing the warning on Debian is correct, but no one
has accepted that responsibility for derived distributions.

Any derived distribution can easily go on record and request inclusion
in the list of distributions where this warning is suppressed, by typing
the phrase "Yes, I understand that this is a bad idea." into an email
client.

I have considerable sympathy for this point of view. Further, given
ongoing (and quite fruitful) discussion on how to resolve the
outstanding issues around /usr-merge and dpkg, I don't think the
question of dpkg's warning (and its unfortunate wording) is one that is
useful for the technical committee (and the dpkg maintainers) to be
spending time on right now.

I think I would feel differently if there were derivatives who had asked
the dpkg maintainers to likewise exclude their distro from the warning
had been rebuffed (though I suspect such folk will just be patching it
out in their own builds).

Likewise I would expect that once we have finished sorting out the
outstanding /usr-merge & dpkg issues that the warning would be removed.

But those scenarios aren't where we're at now, so I think the project
should continue to focus on moving ourselves to the point where dpkg
does support /usr-merge as implemented in Debian.

Regards,

Matthew

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

On Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote:

On a process level, I think I miss attempts to resolve this with the
dpkg maintainer in a constructive way.

The patch was already suggested to the dpkg maintainer and rejected.

Does anyone mind just closing the bug?

Yes, I do.

Please pass a resolution that you don't want to override the dpkg
maintainer and that telling derivative users to configure their system
in a way that will cause breakage is okay to do for packages in Debian.

Ansgar

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

On Tue, 2023-06-06 at 11:04 +0100, Sean Whitton wrote:

I don't think the TC has or should have any authority over dpkg
upstream, but with dpkg being a native package, any implementation of
our decision for the Debian archive is also implemented for dpkg
upstream.  And it might be that the dpkg developers would be against
the TC override solely or mostly because of this fact.  So possibly
changing that would resolve things peacefully.

Given the Debian project owns dpkg.org, the upstream mailing list is @lists.debian.org, official releases are published on deb.debian.org
and so on, I think the Debian project *is* the upstream for dpkg.

Ansgar

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote:

After discussing this at our monthly meeting, we concluded that the technical committee isn't going to take action on this at the moment.
There's a legitimate technical consideration behind the warning, and
it's necessary for derivatives to ensure that they handle the
associated scenarios properly.

Okay, I take that as "Debian doesn't care about derivatives".
Suggesting users to revert to split-/usr *will* break stuff for users
once more code Debian assumes merged-/usr.

While those underlying technical issues exist, we
think it's premature for the committee to intervene on this specific
issue.

Okay, I guess the very long drama about this last year was not
sufficiently long and we did not discuss it in sufficient detail.

I'm a bit disappointed how the ctte appears to do as much as they can
to avoid deciding on this :-(

Ansgar

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

On Tue, Jun 13, 2023 at 09:14:53PM +0200, Ansgar wrote:

On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote:

After discussing this at our monthly meeting, we concluded that the technical committee isn't going to take action on this at the moment. There's a legitimate technical consideration behind the warning, and
it's necessary for derivatives to ensure that they handle the
associated scenarios properly.

Okay, I take that as "Debian doesn't care about derivatives".
Suggesting users to revert to split-/usr *will* break stuff for users
once more code Debian assumes merged-/usr.

With my non-CTTE hat on, I think this is a demonstration that Debian
*does* care about derivatives. It's important to ensure that derivatives
are aware of the subtle interactions between dpkg and usrmerge,
otherwise they may suffer from hard to diagnose issues on upgrades. The
message from dpkg says nothing about reverting to split-/usr, and
instead points at a wiki page. If our documentation on how to avoid
these issues is incomplete (ie, if we're only describing how to avoid it
by using split-/usr rather than describing the mitigations we've imposed
within Debian to avoid triggering the issues), perhaps a better approach
would be to improve that documentation? We don't benefit our users by pretending there isn't a problem here.

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: [email protected]

Matthew Garrett writes:

With my non-CTTE hat on, I think this is a demonstration that Debian
*does* care about derivatives. It's important to ensure that derivatives
are aware of the subtle interactions between dpkg and usrmerge,
otherwise they may suffer from hard to diagnose issues on upgrades. The message from dpkg says nothing about reverting to split-/usr, and
instead points at a wiki page. If our documentation on how to avoid
these issues is incomplete (ie, if we're only describing how to avoid it
by using split-/usr rather than describing the mitigations we've imposed within Debian to avoid triggering the issues), perhaps a better approach would be to improve that documentation? We don't benefit our users by pretending there isn't a problem here.

Okay, I followed your recommendation and added a small warning to the
FAQ: https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=78&rev2=79

Ansgar

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)