Re: merged /usr vs. symlink farms
On Fri, Aug 20, 2021 at 07:56:33AM -0600, Sam Hartman wrote:
> 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.
Thanks, that was my goal: trying to see if we could move the
discussion towards some kind of community consensus.
> 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.
Fair enough. I am unclear on whether we need a dpkg update; I do
believe, though, that even if we needed a dpkg update for some reason,
though, we should explore options other than /usr unification via
symlink farms, which I continue to believe is highly undesirable
choice.
> 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).
Actually, I think we can make a stronger statement than that. Even if
the dpkg bugs relating to directory aliasing which are release
critical in terms of severity (and it's unclear to me whether they
rise to that level), the specifically germane question is whether they
have to be fixed *before* proceeding with the bullseye->bookworm
update. After all, it might be that say, "dpkg-query -S" can fail[1],
but even *if* this were considered priority "serious" --- which I do
not believe --- if it doesn't break upgrading systems, then it can be
fixed when dpkg is upgraded, and we don't have to upgrade dpkg first.
(And again, is it *really* that bad if we tell users that it is
advisable to upgrade dpkg first? TBH, I very often will upgrade dpkg
and apt by hand, before running "apt dist-upgrade" to this day,
because of past experience from upgrades long, long ago... Maybe it's
a cargo cult practice, like typing "sync" three times, but it's not
that hard!)
So perhaps one path forwarwd is to example the breakages listed in
[1], and consider how likely any of them are likely to break upgrades.
I will admit that concerns around update-alternatives and dpkg-divert
sound the scariest --- but I've been using a usrmerged system for a
while, and nothing as broken for me. And as others have pointed out,
Ubuntu has been using usrmerged systems exclusively for a while now,
"going behind dpkg's back", and there doesn't seem to have been a lot
of reports of disaster befalling Ubuntu. Is there things they are
doing to mitigate the potential problems around dpkg-divert and
update-alternatives? What can we learn from the Ubuntu experience?
[1] https://wiki.debian.org/Teams/Dpkg/MergedUsr
> 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.
Agreed. And if the folks who are working can let us know how we can
help determine how we can come to some kind of resolution on those
open technical issues, that would be great. Letting things drag out
isn't going to be helpful, so once we have mature options to consider,
hopefully we can weigh the pros and the cons and come to some kind of
group "hum" about the best path forward.
(And I'm having flashbacks to my days as an IETF working group chair. :-)
- Ted
Reply to: