>>>>> "Theodore" == Theodore Ts'o <ty...@mit.edu> writes:
Theodore> On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
>> In this specific case, I think the thing you're having a problem
>> with is the gradual, file-by-file migration of executables into
>> /usr by individual packages and individual packages'
>> maintainers. That's not merged-/usr: merged-/usr does the
>> migration all at once, by creating the aliasing symlinks (and
>> then we can clean up the contents of data.tar.* to put all
>> /usr-like files below /usr at our leisure, during the next
>> release cycle, without needing maintainer script glue).
Theodore> FWIW, from following the discussion, I've become more and
Theodore> more convinced that a symlink farm is *not* the right
Theodore> answer, regardless of whether it is done centrally or via
Theodore> individual packages moving files and created symlinks if
Theodore> necessary in individual maintainer scripts.
Ted, in terms of judging consensus, I'd like to explicitly ACK your
summary.
I think that you have accurately described where we are in the
discussion.
As you know, one of the ways we can see how close we are on consensus
is to look at what happens when someone proposes a summary like you did.
Simon Richter tried to challenge your summary effectively saying that we
couldn't have an informed consensus because there were open technical
issues that had not been addressed. This was roundly rejected by
yourself, Philip Hands and Luca Boccassi.
Simon's position seemed to be that we need a dpkg update in order to
move forward and that we cannot depend on that mid-release.
You talked about ways we could get a dpkg update at the beginning of the
release process.
Luca and Philip made more structural objections.
Simon did not clearly explain *why* we need a dpkg update.
I can see two arguments why we might need a dpkg update:
1) To fix bugs related to directory aliasing.
I don't think that there is a consensus those bugs need to be fixed to
move forward. (Put another way it's not clear the community agrees they
are RC).
IN particular, most systems are usrmerged today, and while these bugs
are annoying, many people get along just fine.
Yes, there are bugs.
Yes, it would be good to get them fixed in the bookworm cycle.
But despite the issue being brought up, there is not strong support for
the idea that we must block on a solution to the dpkg directory aliasing
bugs.
2)
We might need a dpkg update to actually do the transition.
Thatt is somehow dpkg mechanisms replace what the usrmerge package
does. Or alternatively dpkg mechanisms give us a facility to run
usrmerge early enough.
It's absolutely true that there is an open technical issue of how to
trigger the transition.
However, there are proposed solutions under development that in terms of
being favored in a consensus discussion are preferable to
usr-merge-via-symlink farms:
A) An extraordinary upgrade process. For example requiring that if you
are running on a system that is not usrmerged already, you need to
install usrmerge at the beginning of the upgrade.
(it could still be transitively essential, but explicitly asking people
where it matters to install early).
b) Require that bookworm packages work on non-usrmerged systems and
support non-usrmerged build chroots in the bookworm cycle.
None of these solutions are ideal.
There is still technical work to do, and there a absolutely are open
technical issues.
My reading of the discussion is the same as yours though. We have an
informed consensus that usrmerge-via-symlinks is not the direction we
should take.
I recognize that there are people who are not part of that consensus:
Simon Richter and Guillem Jover among them.
I think the project has given people who are in the rough an opportunity
to present their objections and has taken the time to understood
technical objections that were presented.
I also agree with your reading of the history that there were process
problems in how we interacted with the dpkg team.
I agree with you that is water under the bridge in terms of our
technical decision today.
I hope we choose to learn from that for better future decision making,
but I do not think either our users or the free software community would
be served by letting those process concerns stop technical progress.
signature.asc
Description: PGP signature
