Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello,

On Sat 09 Apr 2022 at 02:52pm +02, Wouter Verhelst wrote:

> On a side note, the dpkg maintainer replied to my message, dropping the
> -ctte Cc, wherein he claims that the warning has been removed:

Yes, it has been removed for some days now -- sorry, thought that was
more widely known.

> https://lists.debian.org/debian-dpkg/2022/04/msg7.html

Thanks for the link.

-- 
Sean Whitton

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

On Sat, 2022-04-09 at 14:52 +0200, Wouter Verhelst wrote:
> On a side note, the dpkg maintainer replied to my message, dropping
> the -ctte Cc, wherein he claims that the warning has been removed:
> 
> https://lists.debian.org/debian-dpkg/2022/04/msg7.html

So one of the statements there is:

| The TC ruling stated that Debian supports for now both layouts

So maybe the dpkg maintainer just missed that we decided to only
support merged-/usr starting with bookworm?

Guillem, please read https://bugs.debian.org/978636#178, relevant part
quoted below:

|The Technical Committee resolves that Debian 'bookworm' should
|support only the merged-usr root filesystem layout, dropping support
|for the non-merged-usr layout.

Maybe the misunderstanding will be resolved with this.

Ansgar

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 12:07:25PM -0700, Sean Whitton wrote:
> Hello Wouter,
> 
> On Fri 08 Apr 2022 at 09:36AM +02, Wouter Verhelst wrote:
> 
> > Given that, in case the dpkg maintainer chooses to remain silent
> > again, I believe the only way forward is for the TC to recommend a GR
> > under §4.2.1 of the consitution.
> 
> Perhaps there is some appropriate GR that at some point it will be
> appropriate for the ctte to propose, but not one with the same text as
> one of our merged-/usr decisions already issued -- that doesn't make
> much constitutional sense, I think.

Well, I think it would -- the TC can always say "we want to get wider
input", and a GR is a proper way to do so, even if the GR is about the
exact thing the TC previously decided on (though that of course doesn't
need to be the case). Perhaps if there is a clearer project-wide
consensus about this, the dpkg maintainer might be convinced?

But that was just a thought, feel free to ignore it :-)

On a side note, the dpkg maintainer replied to my message, dropping the
-ctte Cc, wherein he claims that the warning has been removed:

https://lists.debian.org/debian-dpkg/2022/04/msg7.html

I didn't check any of the claims in his message, but it seems relevant
information.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello Wouter,

On Fri 08 Apr 2022 at 09:36AM +02, Wouter Verhelst wrote:

> Given that, in case the dpkg maintainer chooses to remain silent
> again, I believe the only way forward is for the TC to recommend a GR
> under §4.2.1 of the consitution.

Perhaps there is some appropriate GR that at some point it will be
appropriate for the ctte to propose, but not one with the same text as
one of our merged-/usr decisions already issued -- that doesn't make
much constitutional sense, I think.

-- 
Sean Whitton

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

Hi Helmut,

On Fri, 2022-04-08 at 20:04 +0200, Helmut Grohne wrote:
> We vehemently disagree on how severe those bugs are,
> but at least we've stopped selling them as features it seems.

Could you please give examples where such "selling as a feature"
happened?

Please point to somewhere where someone said the file disappearing bug
(w/ moving between packages & locations) is a feature or similar
things.

> So sooner or later, we want dpkg fixed. Now the ctte cannot tell
> anyone to fix dpkg. All it can do is select between available
> options.

Well, the ctte was asked about the warning added[1]. It has so far not
chosen between available options, such as removal of these warnings. (I
think we do derivates a disservice if dpkg emits these warnings there.)

  [1]: https://lists.debian.org/debian-ctte/2022/03/msg00017.html

> And while Guillem has his own reasons on disliking the existing patch
> everyone else basically agrees that it is not ready for other
> reasons. If that patch were to be decided upon by the ctte in its
> current form, the answer would most likely be "no", not due to change
> in principle, but due to the patch being unfinished.

So talk about that when it happens?

As far as I can tell from the last meeting agenda, the technical
committee doesn't seem to see much technical issues with usrmerge.

Ansgar

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

On Fri, Apr 08, 2022 at 09:39:30AM -0700, Josh Triplett wrote:
> It sounds like at least one patch has already been rejected, not with 
> comments about the patch needing work (which it absolutely does), but AIUI 
> with "usrmerge is broken by design". That seems like sufficient proof that 
> the problem is not a lack of engagement or patches. I don't think it's 
> reasonable to expect further one-sided engagement by way of further "proof" 
> of futility. That's leaving aside the (likely also accurate) expectation 
> based on reported experiences with multiarch that any patch will go through 
> extreme amounts of rework and iteration in that hostile environment, even 
> *if* there were enough trust left to expect good faith.

While this may sound convincing at first, there is another aspect to it.
We basically agree that dpkg is buggy with regard to our current
aliasing approach. We vehemently disagree on how severe those bugs are,
but at least we've stopped selling them as features it seems. So sooner
or later, we want dpkg fixed. Now the ctte cannot tell anyone to fix
dpkg. All it can do is select between available options. And while
Guillem has his own reasons on disliking the existing patch everyone
else basically agrees that it is not ready for other reasons. If that
patch were to be decided upon by the ctte in its current form, the
answer would most likely be "no", not due to change in principle, but
due to the patch being unfinished. So even if Guillem is not being
constructive here, that does not remove the need to fix dpkg.  And if
Guillem does not want to review the patch in a constructive way, then
maybe we should not consider his review relevant. Also putting it to
test would be a relevant data point. (Rumor has it that someone is
working on the latter. :)

Helmut

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On April 8, 2022 6:31:27 AM PDT, Wookey  wrote:
>If they want to prove that no patches for the current approach will
>ever be accepted, that can only be done by engaging further. Yes it
>will be hard work, but if it's not done we are just stuck. 

It sounds like at least one patch has already been rejected, not with comments 
about the patch needing work (which it absolutely does), but AIUI with 
"usrmerge is broken by design". That seems like sufficient proof that the 
problem is not a lack of engagement or patches. I don't think it's reasonable 
to expect further one-sided engagement by way of further "proof" of futility. 
That's leaving aside the (likely also accurate) expectation based on reported 
experiences with multiarch that any patch will go through extreme amounts of 
rework and iteration in that hostile environment, even *if* there were enough 
trust left to expect good faith.

I would love to see some engagement from the dpkg side, beyond reverting NMUs 
and subverting project decisions. Literally a single sentence would largely 
solve this: "as much as I disagree with this decision, I will stop shipping or 
recommending dpkg-fsys-usrunmess, and I will merge a reasonable patch to 
support usrmerge via directory symlinks in dpkg".

In the absence of such engagement, it would help if the TC provided the 
equivalent of both halves of that statement. But in either case, I think it's 
reasonable to not expect people to enthusiastically participate in a hostile 
and gruelling development environment in dpkg in the wake of a TC override 
(whether the one mentioned here or the one that has already taken place).

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Fri, 2022-04-08 at 15:56 +0200, Ansgar wrote:
> On Fri, 2022-04-08 at 14:31 +0100, Wookey wrote:
> > At this point I am more disappointed in the people who keep insisting
> > that 'it mostly works' is good enough, than I am in the bloody-minded
> > dpkg-maintainer. Debian is not a 'mostly works' project. We do things
> > properly - or at least we used to, even if that takes a long time.
> > 
> > Some people have cited the multiarch dpkg changes as an example of
> > work on dpkg being difficult. I was quite closely involved in all
> > that and yes it took a long time but it was done right in the end,
> > and it was the dpkg maintainer who insited on it being done right.
> 
> No, multiarch is in the "mostly works" state.
> 
> If you wanted to do things "properly" (whatever that means), we would
> still not have multiarch (given the bugs are not fixed).
> 
> Ansgar

I find it quite interesting that just the other day, another developer
who is vehemently opposed to merged-usr used multiarch as an example of
a rushed through change that is broken - it was on IRC in public, so I
quote: "He objected to merging multiarch before it was fully done, and
now we're stuck with a broken design that can't handle arch:all
packages well". So depending on who you ask, multiarch goes from being
an example of "we do things properly and it's done right" to "it's
broken", but is always invariably proof that usrmerge is bad either
way.

Considering on Bullseye you can do 'apt install bash:arm64' and hose
your machine by typing "Yes do as I say", it would appear to me the
situation is quite a bit worse than what we and Ubuntu have now with
merged-usr, where the actual worst thing that happens is that sometimes
you have to type 'dpkg -S' twice, once with a prefix and once without.
Yet, I don't think multiarch should be reverted, or it's bad per se.

Also the insistence on "you haven't provided patches" is interesting,
given that first of all a patch was provided some time ago and as far
as we've been told was summarily dismissed as "usrmerge bad", and
secondly there's examples that providing patches doesn't help that much
with this package, if the maintainer doesn't like the change in
principle. See for example zstd support, which is the next ticking bomb
waiting to go off - Ubuntu switched to zstd for all its packages, so
all Ubuntu-built packages are unreadable on Debian right now and for
the foreseeable future - and there's TONS of third-party repositories
with very popular software out there, distributed a single .deb for all
deb-based distros (yes it's bad, but that's how it works), that get
built on Ubuntu. They will likely stop being installable on Debian at
some point, probably as soon as those external build systems get
updated to Jammy. The Ubuntu developers (and others) meticolously
submitted patches, and keep updating them and re-basing and re-
submitting them to dpkg as recently as this week, but as far as I can
tell from the bug tracker the last time the maintainer meaningfully
engaged with them was 4 years ago in 2018.

To me hiding behind "if only you provided patches" seems like badly
misreading the whole situation. The issue isn't technical, it's social,
it's about project governance, following rules we give ourselves, how
collaboration for one of our core packages works in _reality_ (as
opposed as how we think it does or should work), doing what's best for
our users given the realities in the wider world, and how to deal with
a situation that is by now beyond disfunctional. I understand that it
might hurt to hear that the project one really cares about is in a bad
spot, but hiding these problems behind perceived technical issues is
not going to help resolve them.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 02:31:27PM +0100, Wookey wrote:
> On 2022-04-08 09:36 +0200, Wouter Verhelst wrote:
> > 
> > The dpkg maintainer has chosen not to engage with the TC in #994388, and
> > now seems to be actively subverting a validly-made TC decision.
> > 
> > I do believe it reasonable to assume the dpkg maintainer has a point if
> > he believes that the currently-chosen way of moving forward is harmful.
> > However, the right way for him to make that point would have been to
> > engage with the TC, the body constitutionally placed to resolve
> > conflicts of this manner, not ignoring them and then doing whatever he
> > wants when the decision inevitably doesn't go his way.
> 
> > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> > matter. It is not yet too late;
> 
> That all sounds reasonable, but there is the long-standing issue that
> Guillem has never accepted that the TC has authority over the
> project. I forget the details, but given that he does not see it as
> valid it's not surprising that he is not engaging with it. 

Why does that matter? I honestly don't care.

Debian has a set of rules. It's called our "constitution". We all follow
those rules when we engage with the project, for instance when we are
voting.

wouter@pc181009:~/debian/webwml/english/vote$ grep 'guillem' */*voters.txt|wc -l
42

You don't get to exercise your rights in our constitution in one
instance but ignore your duties in another. The constitution exists, and
it is not an optional document. Either you agree by it (and then you get
to vote, etc), or you don't (and then what are you doing here). If one
party can get their way simply by ignoring the rules, then we might as
well pack up and forget this whole Debian thing even happened in the
first place.

There have been cases in the past where Debian has made decisions that I
disagreed with. There have been cases where I seriously considered
leaving the project. In the end, I chose not to do so, in part because
the rules we follow made the decision a fair one, even if I did not
agree with it.

For clarity, and again, I am inclined to agree with the dpkg maintainer
on the matter of how the /usr merge should be implemented; but I am
seriously offended by how he is acting in this manner. This is not how
things should be done.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

On Fri, 2022-04-08 at 14:31 +0100, Wookey wrote:
> At this point I am more disappointed in the people who keep insisting
> that 'it mostly works' is good enough, than I am in the bloody-minded
> dpkg-maintainer. Debian is not a 'mostly works' project. We do things
> properly - or at least we used to, even if that takes a long time.
> 
> Some people have cited the multiarch dpkg changes as an example of
> work on dpkg being difficult. I was quite closely involved in all
> that and yes it took a long time but it was done right in the end,
> and it was the dpkg maintainer who insited on it being done right.

No, multiarch is in the "mostly works" state.

If you wanted to do things "properly" (whatever that means), we would
still not have multiarch (given the bugs are not fixed).

Ansgar

Bug#994388: dpkg currently warning about merged-usr systems

[Wookey]

On 2022-04-08 09:36 +0200, Wouter Verhelst wrote:
> 
> The dpkg maintainer has chosen not to engage with the TC in #994388, and
> now seems to be actively subverting a validly-made TC decision.
> 
> I do believe it reasonable to assume the dpkg maintainer has a point if
> he believes that the currently-chosen way of moving forward is harmful.
> However, the right way for him to make that point would have been to
> engage with the TC, the body constitutionally placed to resolve
> conflicts of this manner, not ignoring them and then doing whatever he
> wants when the decision inevitably doesn't go his way.

> I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> matter. It is not yet too late;

That all sounds reasonable, but there is the long-standing issue that
Guillem has never accepted that the TC has authority over the
project. I forget the details, but given that he does not see it as
valid it's not surprising that he is not engaging with it. 

However he should engage with this dpkg bug. It's an important
one. Guillem, I'm sure you see all this as repeating yourself, but we
cannot either reach a solution, or determine that one is not possible
given current maintainership and TC decisions, without discussing the
details.

Like Wouter, I am inclined to agree with the dpkg maintainer that the
current plan is broken, but I also accept the TC's authority. SFAICT
We've made a right mess of this by not applying our usual technical
rigour (BICBW - I have not followed all the ins and out of this)..

At this point I am more disappointed in the people who keep insisting
that 'it mostly works' is good enough, than I am in the bloody-minded
dpkg-maintainer. Debian is not a 'mostly works' project. We do things
properly - or at least we used to, even if that takes a long time.

Some people have cited the multiarch dpkg changes as an example of
work on dpkg being difficult. I was quite closely involved in all that
and yes it took a long time but it was done right in the end, and it
was the dpkg maintainer who insited on it being done right. Yes there
was an incompatible syntax change but that was due to Ubuntu releasing
with an implementation that was not good enough for upstream. It was
annoying at the time but the pain was fairly short and we ended up in
a better place in the long term. SFAICT the dpkg maintainer is
applying the same rigour here, and the only way to fix this is for
people who want to get usrmerge done to engage, with patches.

If they want to prove that no patches for the current approach will
ever be accepted, that can only be done by engaging further. Yes it
will be hard work, but if it's not done we are just stuck. 

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 03:41:25AM -0700, Felix Lechner wrote:
> Hi,
> 
> On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst  wrote:
> >
> > The nuclear option here is obviously to take maintenance of dpkg away
> > from the dpkg maintainer unless and until he decides to follow the
> > rules.
> 
> This song is for Guillem:
> 
> https://www.youtube.com/watch?v=cnoX81TC6jk

(Stereo MC's - Connected)

I'm not sure what this is supposed to contribute to the discussion? I
think the current situation (where one person in a position of power
decides the rules don't apply to them) is extremely problematic.
Regardless of whether I think the dpkg maintainer is right in this
dispute (and I am inclined towards that position), I think the way he
has chosen to prove his point is not acceptable.

It fails §3 of the code of conduct ("Be collaborative"). Ignoring a
ruling of the TC and just doing your own damn thing is not conducive to
solving the problem. This, to me, is not acceptable.

It fails the "Our Users" bit of the "Our priorities" in the social
contract. Using user pressure to override a technical committee decision
that was taken, even if I may disagree with the merit of that decision,
is not acceptable to me.

Telling users to do one thing when the rest of the project has decided
to do another thing is *not acceptable*. Regardless of who you are.

You may think that the decision is wrong. That's fair. You are given the
option to express that opinion before this committee. If you don't
immediately have time to express that opinion, then you may request more
time. If you think there are other options possible but you need time to
write code to express those other options, then that's fine too and you
can say so.

But remaining silent and then just dropping a bomb like this is not
acceptable, in my opinion, and silly songs don't change that.

But hey, who am I...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Felix Lechner]

Hi,

On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst  wrote:
>
> The nuclear option here is obviously to take maintenance of dpkg away
> from the dpkg maintainer unless and until he decides to follow the
> rules.

This song is for Guillem:

https://www.youtube.com/watch?v=cnoX81TC6jk

Kind regards,
Felix Lechner

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 01:28:16PM +0500, Andrey Rahmatullin wrote:
> On Fri, Apr 08, 2022 at 09:36:21AM +0200, Wouter Verhelst wrote:
> > FWIW, I think the TC should punt this bug to a GR.
> > 
> > The dpkg maintainer has chosen not to engage with the TC in #994388, and
> > now seems to be actively subverting a validly-made TC decision.
> > 
> > I do believe it reasonable to assume the dpkg maintainer has a point if
> > he believes that the currently-chosen way of moving forward is harmful.
> > However, the right way for him to make that point would have been to
> > engage with the TC, the body constitutionally placed to resolve
> > conflicts of this manner, not ignoring them and then doing whatever he
> > wants when the decision inevitably doesn't go his way.
> > 
> > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> > matter. It is not yet too late; the TC can always roll back decisions it
> > made earlier if it believes, in light of new arguments, those decisions
> > to be wrong. However, if this does not happen, then that does not
> > inspire me with confidence that whatever the TC decides after weighing
> > all the arguments available to them, the dpkg maintainer will follow
> > that ruling. Given that, in case the dpkg maintainer chooses to remain
> > silent again, I believe the only way forward is for the TC to recommend
> > a GR under §4.2.1 of the consitution.
> This effectively means "TC cannot enforce its own decisions and everybody
> can ignore them". Also, who would enforce the GR results and how?

I suppose it does. Do you see a better way forward?

> Note that §2.1.1, at least in my opinion, forbids working against a TC
> decision, but doesn't say who would enforce that and how.

Exactly.

The nuclear option here is obviously to take maintenance of dpkg away
from the dpkg maintainer unless and until he decides to follow the
rules. I didn't want to suggest that (I don't think we're quite at that
level yet), but I'm pretty sure someone will put that option on the
ballot should this get to a GR.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Andrey Rahmatullin]

On Fri, Apr 08, 2022 at 09:36:21AM +0200, Wouter Verhelst wrote:
> FWIW, I think the TC should punt this bug to a GR.
> 
> The dpkg maintainer has chosen not to engage with the TC in #994388, and
> now seems to be actively subverting a validly-made TC decision.
> 
> I do believe it reasonable to assume the dpkg maintainer has a point if
> he believes that the currently-chosen way of moving forward is harmful.
> However, the right way for him to make that point would have been to
> engage with the TC, the body constitutionally placed to resolve
> conflicts of this manner, not ignoring them and then doing whatever he
> wants when the decision inevitably doesn't go his way.
> 
> I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> matter. It is not yet too late; the TC can always roll back decisions it
> made earlier if it believes, in light of new arguments, those decisions
> to be wrong. However, if this does not happen, then that does not
> inspire me with confidence that whatever the TC decides after weighing
> all the arguments available to them, the dpkg maintainer will follow
> that ruling. Given that, in case the dpkg maintainer chooses to remain
> silent again, I believe the only way forward is for the TC to recommend
> a GR under §4.2.1 of the consitution.
This effectively means "TC cannot enforce its own decisions and everybody
can ignore them". Also, who would enforce the GR results and how?
Note that §2.1.1, at least in my opinion, forbids working against a TC
decision, but doesn't say who would enforce that and how.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

Hi,

On Tue, Mar 15, 2022 at 03:14:36PM -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
> 
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See .
> 
> This escalation seems in direct contradiction to the tech-ctte decision
> in 994388. Moreover, this seems to effectively use package maintainer
> scripts as a means of directing a complaint at Debian users that has not
> gotten traction in other forums, and then directing such users at a wiki
> page that contradicts a prior project decision.
> 
> This does not even seem to be calling for help in any meaningful way.
> For instance, soliciting help updating dpkg to handle such
> configurations might have been more productive; that still wouldn't be
> appropriate in a maintainer script, but it might have been productive in
> a mail to -devel. But this isn't soliciting help, it's just incorrectly
> declaring the user's system broken.
> 
> This seems counterproductive and harmful.

FWIW, I think the TC should punt this bug to a GR.

The dpkg maintainer has chosen not to engage with the TC in #994388, and
now seems to be actively subverting a validly-made TC decision.

I do believe it reasonable to assume the dpkg maintainer has a point if
he believes that the currently-chosen way of moving forward is harmful.
However, the right way for him to make that point would have been to
engage with the TC, the body constitutionally placed to resolve
conflicts of this manner, not ignoring them and then doing whatever he
wants when the decision inevitably doesn't go his way.

I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
matter. It is not yet too late; the TC can always roll back decisions it
made earlier if it believes, in light of new arguments, those decisions
to be wrong. However, if this does not happen, then that does not
inspire me with confidence that whatever the TC decides after weighing
all the arguments available to them, the dpkg maintainer will follow
that ruling. Given that, in case the dpkg maintainer chooses to remain
silent again, I believe the only way forward is for the TC to recommend
a GR under §4.2.1 of the consitution.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

Hi Luca,

On Tue, Mar 29, 2022 at 12:43:23PM +0100, Luca Boccassi wrote:
> Well, of course it's incomplete - if it is as it appears to be and the
> maintainer refuses to engage in any way, how can any reasonable
> progress be made? Especially in the fact of constantly shifting goal
> posts. First a working patch was needed to make progress. Now it's a
> patch that is working, perfect, and satisfies arbitrary and unspecified
> 'purity' requirements that are left mostly unstated and need to be
> specified by third parties, before the patch can be even looked at. I
> wonder what will be next...

Your way of engaging is anything but constructive. Please stop. I am
unsurprised that communication between you and Guillem does not work
that way. Please reflect on your attitude and behaviour. It is not in
line with our code of conduct.

> You say "how badly this transition is planned and carried out", and yet
> there is tangible proof that it is in fact working fine for all intents
> and purposes, without any major issues, for years and years. Again:
> default for new installations in the past two stable releases, default
> and forcibly transitioned for the past two Ubuntu releases (well, one
> past and one coming next month), plus every other major distro doing
> the same thing, in more or less the same way. The only observed issues
> are minor or solved long ago, or theoretical. In fact, the only
> widespread system breakages that are currently known to have happened
> were caused by the misleading dpkg postinst that was added some days
> ago. And all of this despite obstructionism from the maintainer of the
> involved package. To me this looks like a remarkably successful
> endeavour, all things considered.

The /usr merge has a history of breakage affecting many users. It was
even reverted due to breaking the archive. It has a history of its
proponents not fixing the resulting bugs, but deferring them to others
and/or denying/downgrading them. I've definitely spent more than a week
on fixing /usr-merge breakage excluding the time discussing it. It is
not working fine at all. Possibly, it is fixable on a technical level,
but it is totally broken socially. Please stop this unconstructive
behaviour.

While this may sound single-sided, Guillem's behaviour wrt /usr-merge
cannot be described as constructive either. Rest assured, that side of
the picture is not being ignored. That should also be evident from
dpkg.git at this time.

Helmut

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 11:56:02PM -0700, Josh Triplett wrote:
> On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote:
> > It would appear that the situation has deteriorated further. dpkg 1.21.2
> > now issues a warning on all merged-usr systems:
> > 
> > Setting up dpkg (1.21.2) ...
> > dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> > dpkg: warning: See .
> 
> Update: in dpkg 1.21.3, the warning now reads:
> 
> dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind 
> dpkg's
> dpkg: warning: back, breaking its core assumptions. This can cause silent file
> dpkg: warning: overwrites and disappearances, and its general tools 
> misbehavior.
> dpkg: warning: See .
> 
> While more explicit, I think the issue remains, both with this message
> and with the page it links to.

Update: we're now even further into full-blown "fights in the archive"
territory:

https://lists.debian.org/debian-devel-changes/2022/03/msg03658.html
Changed-By: Bastian Blank 
Changes:
 dpkg (1.21.5+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Revert rebellion against CTTE decision #994388:
 - Remove warning about unsupported system.
 - Don't install dpkg-fsys-usrunmess.

https://lists.debian.org/debian-devel-changes/2022/03/msg03660.html
Changed-By: Guillem Jover 
Changes:
 dpkg (1.21.6) unstable; urgency=medium
 .
   - This also clears a bullying NMU. -
 .
   [ Guillem Jover ]
   * Documentation:
 - man: Document untracked kernel module files handling in
   dpkg-fsys-usrunmess(8).

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Tue, 2022-03-29 at 08:24 +0200, Helmut Grohne wrote:
> Hi Luca,
> 
> On Mon, Mar 28, 2022 at 10:24:03PM +0100, Luca Boccassi wrote:
> > Also worth noting that a couple of days ago, the author wrote on
> > #debian-devel that some time ago the patch was presented to the dpkg
> > maintainer, who rejected it with an answer along the lines of the usual
> > "usrmerge is broken by design", with no further comment.
> 
> That is unfortunate. If I remember correctly, there was some more
> concrete criticism that is still entirely unaddressed in the current
> form.
> 
> dpkg is both a Debian package and an upstream project used by multiple
> distributions with different needs. Guillem generally cares for the
> needs of other distributions. As a result, dpkg separates policy from
> mechanism in a lot of places. The patch at hand however fully
> intermingles them. Which directories are to be aliased could be a
> vendor-specific configuration and should be encoded as such. That kind
> of separation of concerns has not happened at all.
> 
> It should also be noted that the patch describes itself as incomplete.
> No attempt at completing it seems to have been made thus far.

Well, of course it's incomplete - if it is as it appears to be and the
maintainer refuses to engage in any way, how can any reasonable
progress be made? Especially in the fact of constantly shifting goal
posts. First a working patch was needed to make progress. Now it's a
patch that is working, perfect, and satisfies arbitrary and unspecified
'purity' requirements that are left mostly unstated and need to be
specified by third parties, before the patch can be even looked at. I
wonder what will be next...

> > So, what is the next step? Will the those on this thread who asserted
> > they think a correct patch would be accepted without issues try and
> > take it forward themselves?
> 
> I don't think anyone claimed that incomplete patches would go in without
> issues.  Much to the contrary. My experience with sending patches to
> dpkg is that they do go through multiple rounds due to high quality
> feedback. The problem I see here is that communication between patch
> author and dpkg maintainer does not work and thus no progress is being
> made. To be honest, the current form of the patch is a testament of how
> poorly the /usr-merge proponents have spent the last five years on an
> issue that was known for more than ten years.
> 
> The more and more I have to deal with the /usr-merge the more I get
> disappointed by how badly this transition is planned and carried out. In
> principle, the technical merits seem solvable to me, but the total
> failure on the process level leaves me wish for a revert. I am really
> surprised that instead of improving the process, you carry on with that
> destructive attitude. Given this, it seems unsurprising that Guillem
> does not want to interact with you. Of course that's not an excuse for
> implementing the recent changes to dpkg. The communication is clearly
> failing on both sides, which is why we're here at the ctte again.
> 
> The way I see it is that changes need to be well supported regardless of
> how superior their technical approach is. If that's not the case, we
> should not have that change and continue using what has worked in the
> past. I'm sitting on such a change on my own and do not trying to push
> it into Debian hard even though I am strongly convinced of its
> superiority, because doing so would impose unreasonable cost on others.
> There is a social aspect here that is presently failing hard.
> 
> Helmut

You say "how badly this transition is planned and carried out", and yet
there is tangible proof that it is in fact working fine for all intents
and purposes, without any major issues, for years and years. Again:
default for new installations in the past two stable releases, default
and forcibly transitioned for the past two Ubuntu releases (well, one
past and one coming next month), plus every other major distro doing
the same thing, in more or less the same way. The only observed issues
are minor or solved long ago, or theoretical. In fact, the only
widespread system breakages that are currently known to have happened
were caused by the misleading dpkg postinst that was added some days
ago. And all of this despite obstructionism from the maintainer of the
involved package. To me this looks like a remarkably successful
endeavour, all things considered.

Of course it could be better if collaboration rather than
obstructionism was happening. And the end result would have undoubtedly
been better on a technical level. But this is a social issue, not a
technical one - the CTTE made a decision (3 times) and a single
maintianer is vetoing it and actively working against it, because they
don't like it, since day one. How could proponents of the change do
anything about it in this situation? What would you realistically do
differently?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: 

Bug#994388: dpkg currently warning about merged-usr systems

[Marc Haber]

On Tue, Mar 29, 2022 at 08:24:50AM +0200, Helmut Grohne wrote:
> On Mon, Mar 28, 2022 at 10:24:03PM +0100, Luca Boccassi wrote:
> > Also worth noting that a couple of days ago, the author wrote on
> > #debian-devel that some time ago the patch was presented to the dpkg
> > maintainer, who rejected it with an answer along the lines of the usual
> > "usrmerge is broken by design", with no further comment.
> 
> That is unfortunate. If I remember correctly, there was some more
> concrete criticism that is still entirely unaddressed in the current
> form.
> 
> dpkg is both a Debian package and an upstream project used by multiple
> distributions with different needs. Guillem generally cares for the
> needs of other distributions. As a result, dpkg separates policy from
> mechanism in a lot of places. The patch at hand however fully
> intermingles them. Which directories are to be aliased could be a
> vendor-specific configuration and should be encoded as such. That kind
> of separation of concerns has not happened at all.

The easy way to get out of that would be to generalize the issue,
probably somewhere along the line of having a configurable (sic!) list
of lists of directories that are to be treated equally. Unfortunately,
my programming skille as nowhere as good as that I would dare to lay my
hands on a C program as important as dpkg.

> > So, what is the next step? Will the those on this thread who asserted
> > they think a correct patch would be accepted without issues try and
> > take it forward themselves?
> 
> I don't think anyone claimed that incomplete patches would go in without
> issues.  Much to the contrary. My experience with sending patches to
> dpkg is that they do go through multiple rounds due to high quality
> feedback. The problem I see here is that communication between patch
> author and dpkg maintainer does not work and thus no progress is being
> made. To be honest, the current form of the patch is a testament of how
> poorly the /usr-merge proponents have spent the last five years on an
> issue that was known for more than ten years.

Communication with the dpkg maintainer is sometimes difficult. I
remember having some issues with the --path-exclude option that were so
bizarre that I didn't even grok whether this was a code or a
documentation issue, getting terse answers to my question and eventuell
no answers at all. I eventually stopped using the feature, and frankly,
have given up on understanding dpkg entirely.

I am writing this because I understand that being a package maintainer
is not only about technical skills such as coding and documenting, it is
also a communicative challenge, and when you're maintaining a core
program like dpkg is, you need to be even more communicative because so
many people want things from you. It is not the smartest idea to lock
yourself in the cellar and just communicate by doing software releases.

> There is a social aspect here that is presently failing hard.

Yes :-(

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

Hi Luca,

On Mon, Mar 28, 2022 at 10:24:03PM +0100, Luca Boccassi wrote:
> Also worth noting that a couple of days ago, the author wrote on
> #debian-devel that some time ago the patch was presented to the dpkg
> maintainer, who rejected it with an answer along the lines of the usual
> "usrmerge is broken by design", with no further comment.

That is unfortunate. If I remember correctly, there was some more
concrete criticism that is still entirely unaddressed in the current
form.

dpkg is both a Debian package and an upstream project used by multiple
distributions with different needs. Guillem generally cares for the
needs of other distributions. As a result, dpkg separates policy from
mechanism in a lot of places. The patch at hand however fully
intermingles them. Which directories are to be aliased could be a
vendor-specific configuration and should be encoded as such. That kind
of separation of concerns has not happened at all.

It should also be noted that the patch describes itself as incomplete.
No attempt at completing it seems to have been made thus far.

> So, what is the next step? Will the those on this thread who asserted
> they think a correct patch would be accepted without issues try and
> take it forward themselves?

I don't think anyone claimed that incomplete patches would go in without
issues.  Much to the contrary. My experience with sending patches to
dpkg is that they do go through multiple rounds due to high quality
feedback. The problem I see here is that communication between patch
author and dpkg maintainer does not work and thus no progress is being
made. To be honest, the current form of the patch is a testament of how
poorly the /usr-merge proponents have spent the last five years on an
issue that was known for more than ten years.

The more and more I have to deal with the /usr-merge the more I get
disappointed by how badly this transition is planned and carried out. In
principle, the technical merits seem solvable to me, but the total
failure on the process level leaves me wish for a revert. I am really
surprised that instead of improving the process, you carry on with that
destructive attitude. Given this, it seems unsurprising that Guillem
does not want to interact with you. Of course that's not an excuse for
implementing the recent changes to dpkg. The communication is clearly
failing on both sides, which is why we're here at the ctte again.

The way I see it is that changes need to be well supported regardless of
how superior their technical approach is. If that's not the case, we
should not have that change and continue using what has worked in the
past. I'm sitting on such a change on my own and do not trying to push
it into Debian hard even though I am strongly convinced of its
superiority, because doing so would impose unreasonable cost on others.
There is a social aspect here that is presently failing hard.

Helmut

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Fri, 25 Mar 2022 18:04:14 + Luca Boccassi 
wrote:
> On Fri, 2022-03-25 at 11:32 -0600, Gunnar Wolf wrote:
> > Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> > > I am part of that group, and that is definitely _not_ why I
wouldn't
> > > touch dpkg with a barge pole as things stand (and have stood for
> > > years). You are making a gigantic leap with that assumption, not
sure
> > > what you base it on. As a downstream and upstream maintainer in
several
> > > large projects I fix things that don't impact me all the time,
all over
> > > the place.
> > > 
> > > But anyway, it turns out it's all moot because - drum roll -
there is a
> > > patch:
> > > 
> > > https://0x0.st/oNFG.diff
> > > 
> > > This was shared just now on #debian-devel IRC by user 'uau',
linked
> > > here with explicit permission.
> > > 
> > > So it looks like you, Russ and others who chimed in this thread
should
> > > now be in a position to test your theory that a missing patch was
the
> > > only issue. Care to take it forward?
> > 
> > Wow, this is a positive turn of events! Do you happen to have more
> > information as to the identity of the submitter? We should be able
of
> > properly granting attribution...
> > 
> > The patch seems sane from a first, very much 1m-point-of-view.
Of
> > course, it is very situation-specific and not generalized for
> > following any unexpected symlinks in the directory hierarchy, but I
do
> > not expect that to be an issue (as we are talking about a very
> > specific migration here). I am absolutely unfamiliar with dpkg
> > internals and there are some bits that jump to my eye, but I do not
> > think there is much use in me discussing very-minor things that
should
> > be obvious to people who are actually involved with dpkg.
> > 
> > Has this diff been shared with Guillem, or included in any relevant
> > bug report?
> 
> Sorry, I don't know anything more than what I have shared - it was
> linked and briefly discussed by user 'uau' on #debian-devel this
> afternoon. I just happened to be online, noticed it and asked for
> permission to share it here, which was granted. I do not know this
> user, and I do not know if this patch has been shared or discussed
> elsewhere.

The author of the patch today on IRC confirmed that the patch is under
the same license as dpkg (GPL2+), and when asked if they plan to push
it forward, there was no answer. So the license is clear if somebody
else wants to take it forward.

Also worth noting that a couple of days ago, the author wrote on
#debian-devel that some time ago the patch was presented to the dpkg
maintainer, who rejected it with an answer along the lines of the usual
"usrmerge is broken by design", with no further comment.

So, what is the next step? Will the those on this thread who asserted
they think a correct patch would be accepted without issues try and
take it forward themselves?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

On Thu, 2022-03-24 at 09:12 +0100, Ansgar wrote:
> On Tue, 2022-03-15 at 15:14 -0700, Josh Triplett wrote:
> > This escalation seems in direct contradiction to the tech-ctte
> > decision in 994388.
> 
> It already confuses users, for example:

It was pointed out in #-devel that there are bugs in `dpkg-fsys-
usrunmess` that might make systems no longer boot, at least #1008316
and #1008478.

As I suspect more people will try running it due to the newly
introduced warning by dpkg's postinst script, I feel this will
needlessly break user systems. While we can't avoid all such bugs in
programs to move from/to merged-/usr, I believe we should not recommend
users to do such conversions needlessly (given we have decided to move
to merged-/usr previously).

It feels quite unprofessional for the dpkg maintainer to cause this
avoidable breakage of user systems due to his disagreement with the
project's decision.

Ansgar

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Fri, 25 Mar 2022 11:05:26 -0600 Gunnar Wolf  wrote:
> However, even given his attitude, I trust he would apply a correctly
> done patch addressing the issue at hand.

I just read the dpkg git commit
(57e084a52e1ede33b7914c3e0357311ac370a186) that added this warning in
the first place. Quoting the commit message:

> debian: Warn in postinst about merged-/usr-via-aliased-dirs breakage
>
> dpkg does not, and has never supported this filesystem layout even less
> so the way it has been deployed as it bypasses dpkg entirely. It can
> cause file loss, file overwrites, unexpected query results, among other
> things, while being very insidious to detect if one is not aware. Adding
> support for it would be rather infeasible and gets in the way of features
> that have been on the works for some time now.

The last sentence ("Adding support for it would be rather infeasible and
gets in the way of features that have been on the works for some time
now.") would seem to be an objection to adding such support even given a
patch.

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Fri, 2022-03-25 at 11:32 -0600, Gunnar Wolf wrote:
> Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> > I am part of that group, and that is definitely _not_ why I wouldn't
> > touch dpkg with a barge pole as things stand (and have stood for
> > years). You are making a gigantic leap with that assumption, not sure
> > what you base it on. As a downstream and upstream maintainer in several
> > large projects I fix things that don't impact me all the time, all over
> > the place.
> > 
> > But anyway, it turns out it's all moot because - drum roll - there is a
> > patch:
> > 
> > https://0x0.st/oNFG.diff
> > 
> > This was shared just now on #debian-devel IRC by user 'uau', linked
> > here with explicit permission.
> > 
> > So it looks like you, Russ and others who chimed in this thread should
> > now be in a position to test your theory that a missing patch was the
> > only issue. Care to take it forward?
> 
> Wow, this is a positive turn of events! Do you happen to have more
> information as to the identity of the submitter? We should be able of
> properly granting attribution...
> 
> The patch seems sane from a first, very much 1m-point-of-view. Of
> course, it is very situation-specific and not generalized for
> following any unexpected symlinks in the directory hierarchy, but I do
> not expect that to be an issue (as we are talking about a very
> specific migration here). I am absolutely unfamiliar with dpkg
> internals and there are some bits that jump to my eye, but I do not
> think there is much use in me discussing very-minor things that should
> be obvious to people who are actually involved with dpkg.
> 
> Has this diff been shared with Guillem, or included in any relevant
> bug report?

Sorry, I don't know anything more than what I have shared - it was
linked and briefly discussed by user 'uau' on #debian-devel this
afternoon. I just happened to be online, noticed it and asked for
permission to share it here, which was granted. I do not know this
user, and I do not know if this patch has been shared or discussed
elsewhere.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#994388: dpkg currently warning about merged-usr systems

[Gunnar Wolf]

Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> I am part of that group, and that is definitely _not_ why I wouldn't
> touch dpkg with a barge pole as things stand (and have stood for
> years). You are making a gigantic leap with that assumption, not sure
> what you base it on. As a downstream and upstream maintainer in several
> large projects I fix things that don't impact me all the time, all over
> the place.
> 
> But anyway, it turns out it's all moot because - drum roll - there is a
> patch:
> 
> https://0x0.st/oNFG.diff
> 
> This was shared just now on #debian-devel IRC by user 'uau', linked
> here with explicit permission.
> 
> So it looks like you, Russ and others who chimed in this thread should
> now be in a position to test your theory that a missing patch was the
> only issue. Care to take it forward?

Wow, this is a positive turn of events! Do you happen to have more
information as to the identity of the submitter? We should be able of
properly granting attribution...

The patch seems sane from a first, very much 1m-point-of-view. Of
course, it is very situation-specific and not generalized for
following any unexpected symlinks in the directory hierarchy, but I do
not expect that to be an issue (as we are talking about a very
specific migration here). I am absolutely unfamiliar with dpkg
internals and there are some bits that jump to my eye, but I do not
think there is much use in me discussing very-minor things that should
be obvious to people who are actually involved with dpkg.

Has this diff been shared with Guillem, or included in any relevant
bug report?


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Matthew Vernon]

On 25/03/2022 16:25, Russ Allbery wrote:

Luca Boccassi  writes:


But anyway, it turns out it's all moot because - drum roll - there is a
patch:



https://0x0.st/oNFG.diff



This was shared just now on #debian-devel IRC by user 'uau', linked
here with explicit permission.


This is fantastic, thank you so much!  Is the author following this
thread?  Could they get this patch into a git repository forked from dpkg
so that interested parties could start iterating?  I have some concrete
feedback on the patch, and obviously there are a few things that need to
be done before it really could be merged (such as handling the other
architecture directories as noted in the patch introduction), so it needs
some iteration.

That's probably not a good topic for a TC bug, and for various reasons it
may not be best to do early iteration on the dpkg mailing list, so we may
need some other forum.  I'm happy to help out as I have time with patch
review and further feedback.


I'd like to second Russ' note that it's great that a patch exists :)

I'd also like to second the note that the TC (and this bug in 
particular) is emphatically not the place to be working on this patch.


Also, I think the presence and suitability of this patch doesn't change 
the discussion about the warnings that dpkg is currently emitting, which 
are the subject of this bug.


FTR, I think the current warning is inappropriate; a reportbug script 
that flags the known issues with dpkg's support for /usr-merge seems 
like the more appropriate place.


Regards,

Matthew

Bug#994388: dpkg currently warning about merged-usr systems

[Gunnar Wolf]

Russ Allbery dijo [Thu, Mar 24, 2022 at 04:50:44PM -0700]:
> > I think it's appropriate for people to wait on such work until there's
> > guidance from the TC ensuring that such a patch will be accepted.
> > Otherwise, anyone spending time writing it is spending substantial
> > effort that may well be wasted.
> 
> I think this is a totally fair thing to be concerned about.  Should such a
> patch exist -- with the obvious condition that I think it's quite
> reasonable to do several rounds of iteration on making that patch solid,
> ensuring there are tests, and so forth -- I think it's obvious that we
> should merge it given the previous TC decision.  Of course, I'm not a TC
> member.

I have informally talked with some other TC members; I am a TC member,
but am writing just as an individual DD.

You have said the TC has ruled to make an NMU in the past. I doubt an
NMU would fly -- The dpkg maintainer does not want to engage with the
TC, and I believe odds are high we could end up playing NMU
ping-pong. That's not in the best interests of our users nor the
project.

However, TTBOMK, no patches have been proposed. However, even given
his attitude, I trust he would apply a correctly done patch addressing
the issue at hand.

> It's difficult, procedurally, for the TC to do anything about a
> theoretical patch that someone could write but hasn't written.

Precisely. We cannot mandate a patch to be written. We can (and I _do_
think we should) require the maintainer to remove this warning -- not
because it is false, but because torpedoing trust in the project is
not the right course of action.

> If a concrete patch exists, the TC can (and has in the past) authorize an
> NMU to apply it.  Obviously, we should try to avoid reaching that level of
> social and process confrontation if we can avoid it, but this is clearly
> within the TC's constitutional power via a maintainer override, which puts
> the discussion on somewhat firmer ground.  But design of that patch is
> *not* within the TC's constitutional mandate.
> 
> It may be useful to look at how multiarch support in dpkg was handled.
> That was quite painful and I really hope we don't end up following that
> path exactly, but it provides a concrete example of how Debian's processes
> can reach a resolution.
> 
> I personally am still hopeful that we could do much better than the
> multiarch outcome and find a patch that meets the architectural criteria
> of the dpkg maintainer, but I'm fairly certain that we're not going to
> make any progress towards that goal without having working code, or at
> least a very detailed architecture, to start discussing and analyzing.

Completely agree here.

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Luca Boccassi  writes:

> But anyway, it turns out it's all moot because - drum roll - there is a
> patch:

> https://0x0.st/oNFG.diff

> This was shared just now on #debian-devel IRC by user 'uau', linked
> here with explicit permission.

This is fantastic, thank you so much!  Is the author following this
thread?  Could they get this patch into a git repository forked from dpkg
so that interested parties could start iterating?  I have some concrete
feedback on the patch, and obviously there are a few things that need to
be done before it really could be merged (such as handling the other
architecture directories as noted in the patch introduction), so it needs
some iteration.

That's probably not a good topic for a TC bug, and for various reasons it
may not be best to do early iteration on the dpkg mailing list, so we may
need some other forum.  I'm happy to help out as I have time with patch
review and further feedback.

(The biggest concrete piece of feedback that I have is that there is some
weirdness with how searches work that I believe is a result of not having
dpkg convert all of its on-disk databases in a flag-day change.  The point
about having to convert triggers on the fly is very good and one that I
hadn't picked up on before, but I think a flag-day conversion of some of
the other databases would still be better to avoid some edge cases.  I
also suspect it will be easier to merge if we can find a way to provide
cleaner support for non-merged systems even if Debian itself will no
longer support such systems, and I don't think it would be *too*
challenging to do so.  There's also just some super-minor stuff like tabs
vs. spaces, formatting of function signatures, etc., that I'm happy to
help clean up to smooth the path.)

-- 
Russ Allbery (r...@debian.org)  

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Fri, 2022-03-25 at 14:30 +0100, Helmut Grohne wrote:
> On Fri, Mar 25, 2022 at 10:46:01AM +, Luca Boccassi wrote:
> > Let me reverse the question: this stuff has been known and going on for
> > what, 3 years? Why do _you_ think it is that nobody has stepped up to
> > write a patch? In the same time lapse everybody involved has written
> > mountains of code elsewhere. Why do you think this is different?
> 
> I think there are basically three kinds of people in this debate. I'm
> overgeneralizing a little, but I hope you get the message anyway.
> 
> I call the first group "proponents". Those want the /usr-merge to
> happen. Their use cases are not impacted by dpkg -S being broken or dpkg
> deleting files during moves, so they don't care much about the remaining
> bugs. Why would they write the code? It all just works for them.  Most
> likely, Luca is part of this group.

I am part of that group, and that is definitely _not_ why I wouldn't
touch dpkg with a barge pole as things stand (and have stood for
years). You are making a gigantic leap with that assumption, not sure
what you base it on. As a downstream and upstream maintainer in several
large projects I fix things that don't impact me all the time, all over
the place.

But anyway, it turns out it's all moot because - drum roll - there is a
patch:

https://0x0.st/oNFG.diff

This was shared just now on #debian-devel IRC by user 'uau', linked
here with explicit permission.

So it looks like you, Russ and others who chimed in this thread should
now be in a position to test your theory that a missing patch was the
only issue. Care to take it forward?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

On Fri, Mar 25, 2022 at 10:46:01AM +, Luca Boccassi wrote:
> Let me reverse the question: this stuff has been known and going on for
> what, 3 years? Why do _you_ think it is that nobody has stepped up to
> write a patch? In the same time lapse everybody involved has written
> mountains of code elsewhere. Why do you think this is different?

I think there are basically three kinds of people in this debate. I'm
overgeneralizing a little, but I hope you get the message anyway.

I call the first group "proponents". Those want the /usr-merge to
happen. Their use cases are not impacted by dpkg -S being broken or dpkg
deleting files during moves, so they don't care much about the remaining
bugs. Why would they write the code? It all just works for them.  Most
likely, Luca is part of this group.

I call the second group "bystanders". Many of them don't see much point
in the /usr-merge or don't care enough to try and understand it
in-depth.  Some do see the benefits, but may not care enough to invest
their own time into it. They don't want to block the proponents in
changing Debian towards a state where it is applicable to more use
cases. However, these people don't want existing things to break and
they don't want to spend their own time on fixing what is broken by the
/usr-merge. To a limited extend, every change will cause effort
elsewhere, but that has limits.  Their view generally is that it is up
to the proponents to fix the bugs.  Why would they write the code? It's
the job of the proponents.  I consider myself part of this group and
likely Russ and Sean also match here.

And then there is a group I call "opponents". They're a minority by now.
I don't think we need to explain why they don't want to write the code.

So yeah, I do think this is much different to writing mountains of code
elsewhere. Everybody has their own reasons for not doing it. That's a
problem now.

My perception is that the majority of people falls into the bystanders
group and for that reason, I consider them more important than the
others. If the resulting bugs do not get fixed, we may need to consider
other means for limiting their impact. The most obvious method here is
revisiting the decision and considering whether the /usr-merge may have
failed. On a process level, it certainly has failed. At some point, we
may need to look at a bigger picture than the technical one. If the
people driving the change are not able to do it, then maybe we should
not have that change in the first place and revert back to the known
working state. Of course that route is not without cost. What has worked
yesterday, might not work as well today due to upstreams relying on
merged /usr. It will make Debian less compatible with other Linux
distributions and that alone causes work. The answer here is not obvious
to me. However, I think it would be even better if we could avoid having
that discussion, due to it being unnecessary.

Helmut

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Thu, 2022-03-24 at 16:22 -0700, Russ Allbery wrote:
> Luca Boccassi  writes:
> 
> > If it was possible to do it, it would have already happened, and we
> > wouldn't be discussing it at all, it would have just been done.
> 
> Has someone written a patch against dpkg that causes it to do the right
> thing?
> 
> > In the end, at the very least this is a _workable_ proposal. It might
> > not be ideal, but we know it can work. What's your counter-proposal?
> 
> Someone who believes strongly in merged-/usr should write a patch against
> dpkg that causes it to work properly with merged-/usr, including edge
> cases like files moving out of /bin and /lib between packages and dpkg -S
> working properly.
> 
> I understand that you don't think that patch will be accepted.  But we
> don't actually know that since so far as I know it doesn't exist.  We're
> arguing in the abstract about a future problem that hasn't happened yet
> because we don't have working code to argue about.

Let me reverse the question: this stuff has been known and going on for
what, 3 years? Why do _you_ think it is that nobody has stepped up to
write a patch? In the same time lapse everybody involved has written
mountains of code elsewhere. Why do you think this is different?

> 
-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
> 
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See .

Update: in dpkg 1.21.3, the warning now reads:

dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances, and its general tools misbehavior.
dpkg: warning: See .

While more explicit, I think the issue remains, both with this message
and with the page it links to.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 19:24:02 -0700 Sean Whitton  
wrote:
> This is how I see it as well.  Putting aside the postinst warning, the I
> can't see anything the TC could do beyond what we've already done, until
> there's a patch on the table.

I'm glad to hear that the postinst warning is something that could be
addressed regardless.

But also, given that the postinst warning occurred after the previous TC
ruling, I don't think the previous TC ruling alone gives sufficient
confidence that a patch would not be ignored or rejected. I don't think
anyone is expecting the TC to pre-approve a patch sight-unseen; rather,
in the past the TC has used wordings like "merging reasonable
contributions" to give some indication of what the TC expects.

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello,

On Thu 24 Mar 2022 at 04:50PM -07, Russ Allbery wrote:

> Josh Triplett  writes:
>
>> I think it's appropriate for people to wait on such work until there's
>> guidance from the TC ensuring that such a patch will be accepted.
>> Otherwise, anyone spending time writing it is spending substantial
>> effort that may well be wasted.
>
> I think this is a totally fair thing to be concerned about.  Should such a
> patch exist -- with the obvious condition that I think it's quite
> reasonable to do several rounds of iteration on making that patch solid,
> ensuring there are tests, and so forth -- I think it's obvious that we
> should merge it given the previous TC decision.  Of course, I'm not a TC
> member.
>
> It's difficult, procedurally, for the TC to do anything about a
> theoretical patch that someone could write but hasn't written.
> Particularly for dpkg, the details are important.  I can think of some
> ways of supporting merged-/usr that I wouldn't support even while
> supporting the TC decision.  We have various goals (such as being able to
> bootstrap entirely through package installation) that can be met while
> supporting merged-/usr but which do require design and care.
>
> If a concrete patch exists, the TC can (and has in the past) authorize an
> NMU to apply it.  Obviously, we should try to avoid reaching that level of
> social and process confrontation if we can avoid it, but this is clearly
> within the TC's constitutional power via a maintainer override, which puts
> the discussion on somewhat firmer ground.  But design of that patch is
> *not* within the TC's constitutional mandate.
>
> It may be useful to look at how multiarch support in dpkg was handled.
> That was quite painful and I really hope we don't end up following that
> path exactly, but it provides a concrete example of how Debian's processes
> can reach a resolution.
>
> I personally am still hopeful that we could do much better than the
> multiarch outcome and find a patch that meets the architectural criteria
> of the dpkg maintainer, but I'm fairly certain that we're not going to
> make any progress towards that goal without having working code, or at
> least a very detailed architecture, to start discussing and analyzing.

This is how I see it as well.  Putting aside the postinst warning, the I
can't see anything the TC could do beyond what we've already done, until
there's a patch on the table.  Thanks for the summary.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Josh Triplett  writes:

> I think it's appropriate for people to wait on such work until there's
> guidance from the TC ensuring that such a patch will be accepted.
> Otherwise, anyone spending time writing it is spending substantial
> effort that may well be wasted.

I think this is a totally fair thing to be concerned about.  Should such a
patch exist -- with the obvious condition that I think it's quite
reasonable to do several rounds of iteration on making that patch solid,
ensuring there are tests, and so forth -- I think it's obvious that we
should merge it given the previous TC decision.  Of course, I'm not a TC
member.

It's difficult, procedurally, for the TC to do anything about a
theoretical patch that someone could write but hasn't written.
Particularly for dpkg, the details are important.  I can think of some
ways of supporting merged-/usr that I wouldn't support even while
supporting the TC decision.  We have various goals (such as being able to
bootstrap entirely through package installation) that can be met while
supporting merged-/usr but which do require design and care.

If a concrete patch exists, the TC can (and has in the past) authorize an
NMU to apply it.  Obviously, we should try to avoid reaching that level of
social and process confrontation if we can avoid it, but this is clearly
within the TC's constitutional power via a maintainer override, which puts
the discussion on somewhat firmer ground.  But design of that patch is
*not* within the TC's constitutional mandate.

It may be useful to look at how multiarch support in dpkg was handled.
That was quite painful and I really hope we don't end up following that
path exactly, but it provides a concrete example of how Debian's processes
can reach a resolution.

I personally am still hopeful that we could do much better than the
multiarch outcome and find a patch that meets the architectural criteria
of the dpkg maintainer, but I'm fairly certain that we're not going to
make any progress towards that goal without having working code, or at
least a very detailed architecture, to start discussing and analyzing.

-- 
Russ Allbery (r...@debian.org)  

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 16:22:38 -0700 Russ Allbery  wrote:
> Luca Boccassi  writes:
> 
> > If it was possible to do it, it would have already happened, and we
> > wouldn't be discussing it at all, it would have just been done.
> 
> Has someone written a patch against dpkg that causes it to do the right
> thing?
> 
> > In the end, at the very least this is a _workable_ proposal. It might
> > not be ideal, but we know it can work. What's your counter-proposal?
> 
> Someone who believes strongly in merged-/usr should write a patch against
> dpkg that causes it to work properly with merged-/usr, including edge
> cases like files moving out of /bin and /lib between packages and dpkg -S
> working properly.
> 
> I understand that you don't think that patch will be accepted.  But we
> don't actually know that since so far as I know it doesn't exist.  We're
> arguing in the abstract about a future problem that hasn't happened yet
> because we don't have working code to argue about.

I think it's appropriate for people to wait on such work until there's
guidance from the TC ensuring that such a patch will be accepted.
Otherwise, anyone spending time writing it is spending substantial
effort that may well be wasted.

I am also hoping that such a patch is not a precondition for removing
the message from the current dpkg maintainer script, which is already
causing issues.

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Luca Boccassi  writes:

> If it was possible to do it, it would have already happened, and we
> wouldn't be discussing it at all, it would have just been done.

Has someone written a patch against dpkg that causes it to do the right
thing?

> In the end, at the very least this is a _workable_ proposal. It might
> not be ideal, but we know it can work. What's your counter-proposal?

Someone who believes strongly in merged-/usr should write a patch against
dpkg that causes it to work properly with merged-/usr, including edge
cases like files moving out of /bin and /lib between packages and dpkg -S
working properly.

I understand that you don't think that patch will be accepted.  But we
don't actually know that since so far as I know it doesn't exist.  We're
arguing in the abstract about a future problem that hasn't happened yet
because we don't have working code to argue about.

> Sitting back and just saying "someone better get a fix into dpkg",
> without neither doing it nor explaining _how_ that could ever be
> possible is not a workable proposal, it's just doing nothing while
> letting the clock run.

I do not have the resources (time and energy) to write the patch for dpkg
myself, indeed.  However, I also have not been advocating moving to
merged-/usr.  This feels like part of that work to me.

I have been doing some work short of writing the patch, such as laying out
what I think the missing pieces are and trying to propose an
implementation design that could get some consensus, and flush out the
remaining problems.  (To be clear, others have been doing more of that
than I have, but I think it's a bit inaccurate to say that I've only been
complaining and not trying to help arrive at a proper fix.)

-- 
Russ Allbery (r...@debian.org)  

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Thu, 2022-03-24 at 13:24 -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery 
> > wrote:
> 
> > > That said, I personally am disappointed that the folks who have
> > > been
> > > pushing merged-/usr forward are willing to leave dpkg in a known-
> > > buggy
> > > state without attempting to patch it to fix the remaining
> > > issues.  I
> > > realize that there are various obstacles in successfully doing
> > > that,
> > > not all of which are technical,
> 
> > I don't think "willing to" is a fair characterization here.
> 
> It's possible that you haven't seen the discussions that I've been
> in, but
> whenever I point out that this hasn't been fixed and that we should
> fix
> it, I am told, often quite emphatically, that Ubuntu has never seen
> any
> problems and therefore this problem is not important and no one needs
> to
> fix it.  It's hard for me not to characterize this as "willing to"
> leave
> dpkg in a state that I'd characterize as buggy.
> 
> I certainly agree that there are also other challenges in fixing
> dpkg.
> However, it would be nice if we could at least agree that it's
> necessary
> to fix dpkg, rather than arguing that it's fine to leave it in its
> current
> state.  (In fact, I suspect this belief that the current state is
> fine and
> reasonable to leave things in permanently is part of what's making it
> harder to discuss how to best fix dpkg in a way that is sustainable
> and
> supportable going forward.)

You are inverting cause and effect here. We are saying that's it's fine
to write off those small issues because it's believed to be impossible
to get them fixed, and it's thus a very real and reasonable way
forward, not the other way around. It became impossible to get dpkg
fixed long before any of that, and before this latest public
escalation. If it was possible to do it, it would have already
happened, and we wouldn't be discussing it at all, it would have just
been done. But it's obviously not, as recent events show, so either we
decide to give individual maintainers veto rights over the TC when they
personally don't like a committee's decision (but I want to have a veto
too though, or are only "special" maintainers going to have it?), or we
find a way to move forward with the decision.

You might not like to hear it, but it's perfectly legitimate to take a
pragmatic approach and look at a more popular distro, with the same
tools and better infrastructure, more users, more backing, more
deployments etc and see that after all, they are doing just fine, the
sky hasn't fallen, so severity can't really be that bad. The only
perfect and bug-free software is the one that's never been written.
dpkg has literally hundreds of bugs open against it, some decades old,
and yet nobody's screaming bloody murder at them, but somehow this one
spells the end of the world. And in the end I suspect you know
perfectly well _why_ this one is controversial and the hundreds of
others are not.

In the end, at the very least this is a _workable_ proposal. It might
not be ideal, but we know it can work. What's your counter-proposal?
Sitting back and just saying "someone better get a fix into dpkg",
without neither doing it nor explaining _how_ that could ever be
possible is not a workable proposal, it's just doing nothing while
letting the clock run.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 01:24:39PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> 
> >> That said, I personally am disappointed that the folks who have been
> >> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> >> state without attempting to patch it to fix the remaining issues.  I
> >> realize that there are various obstacles in successfully doing that,
> >> not all of which are technical,
> 
> > I don't think "willing to" is a fair characterization here.
> 
> It's possible that you haven't seen the discussions that I've been in, but
> whenever I point out that this hasn't been fixed and that we should fix
> it, I am told, often quite emphatically, that Ubuntu has never seen any
> problems and therefore this problem is not important and no one needs to
> fix it.  It's hard for me not to characterize this as "willing to" leave
> dpkg in a state that I'd characterize as buggy.

I've certainly seen people state that the issues aren't important and
shouldn't be treated as blockers. I haven't seen people assert that
there are no issues at all without being corrected, just that they're
not important issues and not blockers. (That of course does not mean it
hasn't happened.) And I haven't seen assertions that we *shouldn't* fix
dpkg if dpkg is actually amenable to fixing.

If nothing else, the behavior of `dpkg -S` seems like a clear
counterexample that anyone on a usrmerge'd system can easily observe
themselves, leaving aside the more subtle issues with file migrations
and file conflicts. The debate over the severity of those issues seems
like it took place as part of the previous decision, though.

> I certainly agree that there are also other challenges in fixing dpkg.
> However, it would be nice if we could at least agree that it's necessary
> to fix dpkg, rather than arguing that it's fine to leave it in its current
> state.  (In fact, I suspect this belief that the current state is fine and
> reasonable to leave things in permanently is part of what's making it
> harder to discuss how to best fix dpkg in a way that is sustainable and
> supportable going forward.)

That's fair. It wouldn't surprise me at all if there are *multiple*
non-technical factors playing off each other here: expectation that
patches would be rejected, conflation between "not a blocker" and "not
an issue at all", and just general aversion to getting in the middle of
a flamewar-inviting issue. I do think this has become an adversarial
issue and gotten escalated excessively, which has absolutely compromised
the ability and inclination to fix it.

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Josh Triplett  writes:
> On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:

>> That said, I personally am disappointed that the folks who have been
>> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
>> state without attempting to patch it to fix the remaining issues.  I
>> realize that there are various obstacles in successfully doing that,
>> not all of which are technical,

> I don't think "willing to" is a fair characterization here.

It's possible that you haven't seen the discussions that I've been in, but
whenever I point out that this hasn't been fixed and that we should fix
it, I am told, often quite emphatically, that Ubuntu has never seen any
problems and therefore this problem is not important and no one needs to
fix it.  It's hard for me not to characterize this as "willing to" leave
dpkg in a state that I'd characterize as buggy.

I certainly agree that there are also other challenges in fixing dpkg.
However, it would be nice if we could at least agree that it's necessary
to fix dpkg, rather than arguing that it's fine to leave it in its current
state.  (In fact, I suspect this belief that the current state is fine and
reasonable to leave things in permanently is part of what's making it
harder to discuss how to best fix dpkg in a way that is sustainable and
supportable going forward.)

-- 
Russ Allbery (r...@debian.org)  

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> I think this accidentally confuses the related states of "unsupported" and
> "buggy."  We know that merged-/usr is buggy, in that one can construct a
> set of package operations that leave the system in an invalid state.  We
> have a project disagreement over how serious those bugs are.  No one is
> stepping forward to fix those bugs, which is indeed quite unfortunate.  I
> personally strongly disagree with the belief that simply because Ubuntu
> hasn't seen many instances of this class of bugs while using a package set
> where people have not moved files between packages and out of /lib and
> /bin very much if at all, it is acceptable to leave dpkg in that buggy
> state.
> 
> However, I think this is similar to many other disagreements over the
> severity of bugs, particularly ones that are hard to fix.  It doesn't
> really imply that this configuration is *unsupported*, which would mean
> that if someone had a system in that state and reported a problem we would
> say that we couldn't help them because their system is not in a supported
> configuration.  This is not the case; merged-/usr is supported in that
> sense.  Guillem may not be willing to support the user in that case but
> other people most certainly would.
> 
> That said, I personally am disappointed that the folks who have been
> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> state without attempting to patch it to fix the remaining issues.  I
> realize that there are various obstacles in successfully doing that, not
> all of which are technical,

I don't think "willing to" is a fair characterization here. It does not
seem at all obvious that such patches would have been accepted, given
the repeated vehement objections from the dpkg maintainer about the
chosen approach. Those objections did not invite contribution; at every
point, the assertion was that usrmerge was broken, not that dpkg needed
help supporting it. In particular, while I've seen the dpkg maintainer
call for implementing *different* approaches to merged /usr, I have not
seen even the slightest hint that patches implementing merged /usr in
the fashion the TC decided upon would be accepted.

I think those who might otherwise have been willing to write such
patches could be forgiven for thinking they'd be unwelcome.

I'm hoping that the TC may be able to address that exact issue.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 18:56:54 +0100 Helmut Grohne  wrote:
> On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> > We should distinguish two senses of "supported".
> > 
> > There is the sense of what Debian-the-project supports.  That is
> > specified in the TC decision.  That is not subjective.
> 
> This could be a language issue on my side. As I see it, the Debian
> project clearly endorses merged-/usr. I have difficulties calling it
> support, because that would go in hand with fixing the resulting
> problems - which is not happening. In my reading, support is an activity
> rather than a statement. That activity is missing. I even ran into
> /usr-merge fallout in 2022 myself. The statement is clear enough and
> Guillem's warning is clearly not helping the state of affairs.
> 
> > The difficulty is that Guillem's warning kind of refers to both.
> 
> Yeah, I see how you get there. It is fully in line with the confusion I
> see elsewhere.
> 
> Let us try to turn this upside down: How can Guillem express his
> dissatisfaction with the current process in a way that does not cause
> harm? Guillem has to deal with quite a number of /usr-merge-caused bugs.
> Many of them lack patches and/or are duplicating existing ones. In cases
> patches were posted (e.g. dpkg-shlibdeps), Guillem has included them.

There are two separate issues here: dissatisfaction with Debian's chosen
approach to the /usr-merge issue, and dissatisfaction with dpkg not
natively supporting Debian's chosen approach.

For the former, that decision is made, and while anything can be
*discussed* and a new decision could theoretically be made in the
future, that doesn't change or invalidate the decision as already made.
Delete the "usrunmess" script and most of the contents of the Dpkg
usrmerge "FAQ".

For the latter, that's *absolutely* reasonable. Even if (as extensively
discussed) larger issues don't tend to arise in practice, there are real
issues such as `dpkg -S` not handling search paths as expected (`dpkg -S
/bin/ls` vs `dpkg -S /usr/bin/ls`), as well as issues making it harder
to migrate packages to "natively" have files in /usr eventually. And if
users are filing bugs about such issues, it'd be entirely reasonable to
close or merge such bugs, referencing to one or a few bugs tracking the
lack of usrmerge support.

It would also be entirely reasonable to call for help fixing such
issues. It's entirely possible that someone would have written dpkg
patches *already*, if the pitched battles over usrmerge hadn't made it
abundantly clear how such patches would be received (and, at the moment,
likely *still* would be received). I think that has unnecessarily
delayed any efforts to actually help with this.

The maintainer script was not such a call for help, at all. And it has
already caused harm, and is continuing to do so.

As it stands, I think the path forward would be:

1) Delete the message from the maintainer script, immediately, and
   upload a new version of dpkg with that message removed. Don't add any
   new such user-targeted messages in that or other places (e.g.
   Description).
2) Issue a call for help *supporting* the established approach to
   usrmerge, not subverting and relitigating it.
   2.1) Make it clear that dpkg patches to fix issues related to
usrmerge, as well as updates to the documentation (including the
wiki), will not be unreasonably blocked on the basis of dislike
for usrmerge. (This will be necessary to make (2) successful.)
3) Delete `dpkg-fsys-usrunmess`.
4) File one or more bugs, or select existing representative bugs that
   don't have too much noise in them, about dpkg support for usrmerge
   (ranging from `dpkg -S` to the handling of files moving from / to
   /usr to the handling of file conflicts between packages).
5) Close or merge any new and existing dpkg bugs about merged /usr,
   pointing to the appropriate representative bug(s).

I think it would be appropriate for the TC to issue a ruling regarding
points (1), (2.1), and (3) above, and optionally to issue advice
suggesting (2), (4), and (5).

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

Hi Sean,

On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> We should distinguish two senses of "supported".
> 
> There is the sense of what Debian-the-project supports.  That is
> specified in the TC decision.  That is not subjective.

This could be a language issue on my side. As I see it, the Debian
project clearly endorses merged-/usr. I have difficulties calling it
support, because that would go in hand with fixing the resulting
problems - which is not happening. In my reading, support is an activity
rather than a statement. That activity is missing. I even ran into
/usr-merge fallout in 2022 myself. The statement is clear enough and
Guillem's warning is clearly not helping the state of affairs.

> The difficulty is that Guillem's warning kind of refers to both.

Yeah, I see how you get there. It is fully in line with the confusion I
see elsewhere.

Let us try to turn this upside down: How can Guillem express his
dissatisfaction with the current process in a way that does not cause
harm? Guillem has to deal with quite a number of /usr-merge-caused bugs.
Many of them lack patches and/or are duplicating existing ones. In cases
patches were posted (e.g. dpkg-shlibdeps), Guillem has included them.

Part of the answer would have been talking to the ctte at the time the
decision was made. It's sad that he opted for not doing that.

Helmut

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Helmut Grohne  writes:

> What is supported is a bit subjective I fear. At this point, neither
> merged-/usr nor unmerged-/usr is supported well. Both are broken in one
> way or another and nobody steps up to fix the mess. In particular, the
> dpkg maintainer does not support merged-/usr in dpkg (which is his
> constitutional right as long as he does not block reasonable patches),
> but neither does anyone else.

I think this accidentally confuses the related states of "unsupported" and
"buggy."  We know that merged-/usr is buggy, in that one can construct a
set of package operations that leave the system in an invalid state.  We
have a project disagreement over how serious those bugs are.  No one is
stepping forward to fix those bugs, which is indeed quite unfortunate.  I
personally strongly disagree with the belief that simply because Ubuntu
hasn't seen many instances of this class of bugs while using a package set
where people have not moved files between packages and out of /lib and
/bin very much if at all, it is acceptable to leave dpkg in that buggy
state.

However, I think this is similar to many other disagreements over the
severity of bugs, particularly ones that are hard to fix.  It doesn't
really imply that this configuration is *unsupported*, which would mean
that if someone had a system in that state and reported a problem we would
say that we couldn't help them because their system is not in a supported
configuration.  This is not the case; merged-/usr is supported in that
sense.  Guillem may not be willing to support the user in that case but
other people most certainly would.

That said, I personally am disappointed that the folks who have been
pushing merged-/usr forward are willing to leave dpkg in a known-buggy
state without attempting to patch it to fix the remaining issues.  I
realize that there are various obstacles in successfully doing that, not
all of which are technical, but I want to believe that Debian is the sort
of project that will do the hard work (both technical and social) to fix
edge cases and maintain a high level of consistency and correctness.

-- 
Russ Allbery (r...@debian.org)  

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello Helmut,

On Thu 24 Mar 2022 at 02:49pm +01, Helmut Grohne wrote:

> Hi,
>
> On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
>> Maybe it should be changed into a warning that non-merged-/usr systems
>> will not be supported in the future.  The `dpkg-fsys-usrunmess` program
>> should probably also include a warning that it will convert the system
>> into a state no longer supported by Debian in the future.
>
> What is supported is a bit subjective I fear. At this point, neither
> merged-/usr nor unmerged-/usr is supported well. Both are broken in one
> way or another and nobody steps up to fix the mess.

We should distinguish two senses of "supported".

There is the sense of what Debian-the-project supports.  That is
specified in the TC decision.  That is not subjective.

There is the sense of what Debian-the-archive-contents supports.  That
is indeed subjective just as you explain.  There exists disagreement
about whether the Ubuntu approach to implementing merged-/usr is adequate.

The difficulty is that Guillem's warning kind of refers to both.

-- 
Sean Whitton

Bug#994388: dpkg currently warning about merged-usr systems

[Luca Boccassi]

On Thu, 2022-03-24 at 15:06 +0100, Ansgar wrote:
> On Thu, 2022-03-24 at 14:49 +0100, Helmut Grohne wrote:
> > On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> > > Maybe it should be changed into a warning that non-merged-/usr
> > > systems
> > > will not be supported in the future.  The `dpkg-fsys-usrunmess`
> > > program
> > > should probably also include a warning that it will convert the
> > > system
> > > into a state no longer supported by Debian in the future.
> > 
> > What is supported is a bit subjective I fear.
> 
> No, Helmut, it is not. We had that discussion often enough and in this
> bug report you will find the following:
> 
> +---
> > There are currently Debian 11 installations with both the merged-/usr
> > and non-merged-/usr filesystem layouts. All of these installations
> > should successfully upgrade via normal upgrade paths to a merged-/usr
> > Debian 12.  Only after the release of Debian 12 can packages assume
> > that all installations will be merged-/usr.
> +---
> 
> I'm not motivated to pretend the last years did not happen.
> 
> Feel free to start a GR to override the tech ctte if you think that is
> necessary.
> 
> > > Either way, given related questions were already before the tech
> > > ctte
> > > several times it would be nice if this could be decided quickly to
> > > avoid this becoming yet another energy drain (we had several
> > > sufficiently long enough threads about this topic already).
> > 
> > As much as I'd like to see this resolved quickly, I fear it is
> > blocked on the lack of patches supporting merged-/usr.
> 
> Given all new installations have been merged-/usr for years, it seems
> to work sufficiently well for real-world use.

And on top of new installations, old installations of Ubuntu upgrading
to 21.10 and/or the soon-to-be-released 22.04 have been forcifully
migrated too. They are not blocked, unsupported, or broken.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

On Thu, 2022-03-24 at 14:49 +0100, Helmut Grohne wrote:
> On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> > Maybe it should be changed into a warning that non-merged-/usr
> > systems
> > will not be supported in the future.  The `dpkg-fsys-usrunmess`
> > program
> > should probably also include a warning that it will convert the
> > system
> > into a state no longer supported by Debian in the future.
> 
> What is supported is a bit subjective I fear.

No, Helmut, it is not. We had that discussion often enough and in this
bug report you will find the following:

+---
| There are currently Debian 11 installations with both the merged-/usr
| and non-merged-/usr filesystem layouts. All of these installations
| should successfully upgrade via normal upgrade paths to a merged-/usr
| Debian 12.  Only after the release of Debian 12 can packages assume
| that all installations will be merged-/usr.
+---

I'm not motivated to pretend the last years did not happen.

Feel free to start a GR to override the tech ctte if you think that is
necessary.

> > Either way, given related questions were already before the tech
> > ctte
> > several times it would be nice if this could be decided quickly to
> > avoid this becoming yet another energy drain (we had several
> > sufficiently long enough threads about this topic already).
> 
> As much as I'd like to see this resolved quickly, I fear it is
> blocked on the lack of patches supporting merged-/usr.

Given all new installations have been merged-/usr for years, it seems
to work sufficiently well for real-world use.

Ansgar

Bug#994388: dpkg currently warning about merged-usr systems

[Helmut Grohne]

Hi,

On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> Maybe it should be changed into a warning that non-merged-/usr systems
> will not be supported in the future.  The `dpkg-fsys-usrunmess` program
> should probably also include a warning that it will convert the system
> into a state no longer supported by Debian in the future.

What is supported is a bit subjective I fear. At this point, neither
merged-/usr nor unmerged-/usr is supported well. Both are broken in one
way or another and nobody steps up to fix the mess. In particular, the
dpkg maintainer does not support merged-/usr in dpkg (which is his
constitutional right as long as he does not block reasonable patches),
but neither does anyone else. As such I find it difficult to disagree
with the content of the warning. I do see how it confuses people. It
definitely does not reach people who could do something about. Rather it
takes users as hostages. This is similar to the case where debianutils
added deprecation warnings. I would not have added such a warning even
if it were fully accurate.

> Either way, given related questions were already before the tech ctte
> several times it would be nice if this could be decided quickly to
> avoid this becoming yet another energy drain (we had several
> sufficiently long enough threads about this topic already).

As much as I'd like to see this resolved quickly, I fear it is blocked
on the lack of patches supporting merged-/usr.

Helmut

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

On Tue, 2022-03-15 at 15:14 -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg
> 1.21.2
> now issues a warning on all merged-usr systems:
> 
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See
> .
> 
> This escalation seems in direct contradiction to the tech-ctte
> decision in 994388.

It already confuses users, for example:

- 
https://old.reddit.com/r/debian/comments/tew0w7/whats_going_on_with_dpkg_and_usrmerge/
- https://lwn.net/Articles/889026/

Maybe it should be changed into a warning that non-merged-/usr systems
will not be supported in the future.  The `dpkg-fsys-usrunmess` program
should probably also include a warning that it will convert the system
into a state no longer supported by Debian in the future.

Either way, given related questions were already before the tech ctte
several times it would be nice if this could be decided quickly to
avoid this becoming yet another energy drain (we had several
sufficiently long enough threads about this topic already).

Ansgar

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello,

On Wed 16 Mar 2022 at 08:55am -07, Russ Allbery wrote:

> Sean Whitton  writes:
>
>> Thanks for the pointer.  It's only in the postinst, it seems.  So this
>> is only going to get emitted once per system and only on upgraded
>> systems.
>
> I think the concern is less about the noise and more about the fact that
> this will be perceived by users as an official declaration from Debian as
> a project that their system configuration is unsupported, while
> simultaneously this is the default installation mode for new systems and
> something that we have elsewhere said is a correct system configuration.

Right, I share this concern, I just wanted to be completely clear about
the scope of the issue.

-- 
Sean Whitton

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Sean Whitton  writes:

> Thanks for the pointer.  It's only in the postinst, it seems.  So this
> is only going to get emitted once per system and only on upgraded
> systems.

I think the concern is less about the noise and more about the fact that
this will be perceived by users as an official declaration from Debian as
a project that their system configuration is unsupported, while
simultaneously this is the default installation mode for new systems and
something that we have elsewhere said is a correct system configuration.

-- 
Russ Allbery (r...@debian.org)  

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello,

On Wed 16 Mar 2022 at 12:39am -07, Josh Triplett wrote:

> On March 15, 2022 11:38:44 PM PDT, Sean Whitton  
> wrote:
>>Hello Josh,
>>
>>On Tue 15 Mar 2022 at 03:14pm -07, Josh Triplett wrote:
>>
>>> It would appear that the situation has deteriorated further. dpkg 1.21.2
>>> now issues a warning on all merged-usr systems:
>>>
>>> Setting up dpkg (1.21.2) ...
>>> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
>>> dpkg: warning: See .
>>
>>Does this happen just when configuring dpkg.deb here, or does the
>>warning get issued at other times, have you seen?
>>
>
> Just dpkg. It's mentioned in the changelog.

Thanks for the pointer.  It's only in the postinst, it seems.  So this
is only going to get emitted once per system and only on upgraded
systems.

-- 
Sean Whitton

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On March 15, 2022 11:38:44 PM PDT, Sean Whitton  
wrote:
>Hello Josh,
>
>On Tue 15 Mar 2022 at 03:14pm -07, Josh Triplett wrote:
>
>> It would appear that the situation has deteriorated further. dpkg 1.21.2
>> now issues a warning on all merged-usr systems:
>>
>> Setting up dpkg (1.21.2) ...
>> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
>> dpkg: warning: See .
>
>Does this happen just when configuring dpkg.deb here, or does the
>warning get issued at other times, have you seen?
>

Just dpkg. It's mentioned in the changelog.

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello Josh,

On Tue 15 Mar 2022 at 03:14pm -07, Josh Triplett wrote:

> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
>
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See .

Does this happen just when configuring dpkg.deb here, or does the
warning get issued at other times, have you seen?

-- 
Sean Whitton

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

It would appear that the situation has deteriorated further. dpkg 1.21.2
now issues a warning on all merged-usr systems:

Setting up dpkg (1.21.2) ...
dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
dpkg: warning: See .

This escalation seems in direct contradiction to the tech-ctte decision
in 994388. Moreover, this seems to effectively use package maintainer
scripts as a means of directing a complaint at Debian users that has not
gotten traction in other forums, and then directing such users at a wiki
page that contradicts a prior project decision.

This does not even seem to be calling for help in any meaningful way.
For instance, soliciting help updating dpkg to handle such
configurations might have been more productive; that still wouldn't be
appropriate in a maintainer script, but it might have been productive in
a mail to -devel. But this isn't soliciting help, it's just incorrectly
declaring the user's system broken.

This seems counterproductive and harmful.