Re: [pre-GR] Requirements for usrmerge
Hi,
This has become such a toxic and painful topic, that I really do not
have the energy nor motivation to be dragged into this again, sorry.
This is most probably my only reply on this topic in here.
On Mon, 2022-09-19 at 01:16:59 +0200, Adam Borowski wrote:
> […] And Guillem did agree to
> a plan, describing requirements for a patchset that would be acceptable
> by him (see below). That would fix a good part of the issues, and is
> conceptually simple.
I don't recall ever agreeing to any such plan, see below too.
> (the agreed upon patchset goes most of the way),
Again, I don't really know what that «agreed upon patchset» refers
to.
> Who has the reverse:
> * GNU Hurd (/usr → /)
This was a local port experiment that didn't last too long, as that
added a bunch of extra work for porters that were already spread thin,
on something that was not supported at all by the main Debian ports.
It's been years since this got dropped from the Hurd port.
> ============
> The Debian project refuses to override the dpkg maintainer.
> There shall be no enablement of usrmerge until the following conditions
> are met:
> * the proponents provide a patchset that fixes aliasing bugs in dpkg
> according to the plan previously agreed with Guillem: that is, a
> configurable set of aliased paths are used to redirect writes.
I don't think I've ever agreed to this as any kind of plan. I think I
floated this idea on some bug report as a potential solution, which I
then discarded early on when I realized it was just too hacky and
problematic, and a bad workaround.
What I've also mentioned on some of the threads of doom on d-d, was
that a potential foundation for supporting this might start with the
work I've been doing to enable fsys metadata tracking, which cannot
currently be deployed anyway as it is blocked, and that alone would
require one or two full release cycles to be able to use it. And I've
also mentioned that this foundation does not guarantee the required
work on top, has clear or sound semantics, etc, or that it does not
make other things unfeasible… so here I've also not agreed to anything
with anyone (just to make this clear).
Also, of course this would force me to have to directly interact with
the "proponents", with some of whom I've had the most taxing and
unpleasant interactions I can recall in Debian, to the point of what
I've perceived as bullying, when some threatened with expulsion,
demotion, forceful maintainership removal, etc. This has been a
source of anxiety and massive amounts of stress and unhappiness,
so I honestly don't want to be dragged into this. :(
(And just to be extra clear, to avoid any potential misreading, I'm
always open to reconsider previous decisions based on new data or
ideas *and* interact with pleasant and respectful people, on topics
and solutions I might disagree with (even strongly), be those technical
or social or whatever. Even on this one. I also, for a volunteer project,
will choose any single time being left alone to solve that kind of stuff
on my own, than being forced to get unpleasant "help".)
:(
Spent,
Guillem
Reply to: