Hi,
On 7/7/23 16:55, Helmut Grohne wrote:
If we have a consensus we're unwilling to wait for a patch, it doesn't
matter whether that's because:
While you try to remove the reasoning for this point of view
from the consensus, the "willing to wait" language implies a reason of
"too slow" already.
The main problem I see with that language is that it is entirely
passive, as if a patch would appear by waiting for it to do so.
Right now, I seem to be the only person working on one, which is clearly
ridiculous, as I can invest maybe a total of four hours per week into
it, so obviously I need to be realistic here and say that it is a bad
idea for the project to wait for me to implement this, and I don't want
to be in the position of having the project wait for me either because I
already have that in 60 hours of my life between Monday and Friday.
We also have quite some disagreement on what "the patch" is in terms of
what semantics would help here.
Yes, that's underspecified. I've tried to get started on this in
<c3c4bea2-4a33-129d-0ac4-9dbb5552d...@hogyros.de> [1], that is by no
means complete but it has not generated any comments either.
If there is interest in dpkg changes as a solution, then I could add
this to the document.
I carefully avoided adding reasoning to the proposed consensus as I was
seeing our disagreement on reasoning. I now see how that second sentence
could be read as precluding a dpkg patch in general. Would it help to
add "+For the purpose of finalizing the transition,+ dpkg is not
augmented ..." to leave open the possibility to add such a change but
still implying that we are not waiting for it to happen?
Yes, that was why I objected to that wording as well. I do agree that we
need to move forward without waiting for a patch, if only out of the
self-serving interest that I don't want to sit on the critical path.
I think we need consensus on decisions and confirmation that everyone
feels heard.
Heh. I see how you get there. I agree with that latter part and tried
to use the agreement on problems and mitigations as a vehicle for
ensuring that everyone feels heard. Evidently, that does not work out
either.
It's the best way I can see to reach a consensus, but consensus, like
voting, can only allocate resources and modify procedures.
If we have a viable technical procedure that finishes the transition,
then we can get consensus to implement it.
If we have a technical procedure that requires changing a procedure to
be viable (such as lock-step upgrade of packages in the archive so the
installer is never presented with an inconsistent set), then we can get
consensus to modify the procedure and implement the solution.
However, if there are open questions about the technical viability of a
solution, then the answer to those should be technical as well.
Hence my suggestion to say we have consensus to focus our efforts on the
solution space that doesn't require a dpkg change -- that is purely an
allocation of resources, and the remainder of the document is a very
useful collection of the knowledge we have gathered so far, the avenues
that have been investigated and possible blockers for those.
We can also try to get consensus or votes on expanding the solution space:
- mitigations that require archive-side changes, like an upload check
that a package doesn't trigger a known file loss condition
- mitigations that require users to upgrade using a special procedure
- mitigations that (further) violate policy by e.g. manipulating the
dpkg database from the usrmerge package, or wrapping dpkg in a diversion
- mitigations that require updating a stable release, such as shipping
an updated debootstrap package
I'm not sure all of these would be unanimous, but if there is a
technical solution that becomes viable through something we can vote on,
that is completely valid.
In any case, the rough consensus on moving forward without major changes
to dpkg (for reasons we disagree about) paves the road for selecting a
subset of mitigations and proposing that as decision. The major missing
piece to perform this selection is an agreement on how we protect
aliasing symlinks from deletion (aka P9), because we still have quite
strong disagreement on the mitigations selected there.
The questions I see are
- Can we get a full column of checkmarks by any combination of
mitigations?
- Are there procedural mitigations that can be useful?
- Are these mitigations mutually compatible?
Simon
[1] https://lists.debian.org/debian-dpkg/2023/06/msg00050.html
