Hi. I have read both of your messages over the weekend multiple times. I don't think replying point-by-point is going to be all that helpful, although if there are any cases where you'd like me to do that, I will.
* I am really impressed with the work you are putting in on all this.
You have done an amazing job at a really hard problem.
* Mostly, I popped into this discussion to try and help confirm
consensus. I think my participation has come close to outliving its
usefulness. I am not involved in this problem enough to be running
experiments, and I am probably not going to go dig into the guts of
dpkg to start looking for problems that we might be overlooking.
* The more I look at this, I think the real complexity is not in
bootstrapping, but is in the rest of the proposal for canonicalizing
paths. I am very uncomfortable overall; it seems complicated enough
that we probably will break something somewhere. I do not see anry
better options though. I think this affects things in a couple ways:
* I hope we can put the bootstrapping decision behind us soon and
focus on the harder problem, because I think bootstrapping is a bit
of a bikeshed at this point.
* I hope that we're open to better ideas of doing things proposed even
fairly late in the process. If someone finds ways of removing
complexity that we don't see now, I think it is worth seriously
considering even if implementation has already started.
* I think the bootstrapping decision may not be something we need a
project consensus on. If the people involved can get to something
that works for them, that's probably good enough. So, mmdebstrap
maintainer, people who have worked on debootstrap recently, with no
significant objections from base-files, glibc, or other major
essential packages.
* I think your most recent mail really helps explain 3C, and I agree
that is a proposal that someone sufficiently knowledgable could
evaluate for safety. I do not feel comfortable enough with my
knowledge of dpkg-divert to say "looks good to me," although I am now
more comfortable with 3C than I was earlier.
* Mitigation M-4 introduces what appear to me to be some undesirable
properties we should at least document. We appear to be depending
heavily on limitations of dpkg-divert. In particular, we're depending
on the idea that diversions don't work for directories. So we're
introducing yet more cases where dpkg's view of the world is different
than reality. We're doing more things that would make it difficult
for the dpkg maintainer if they actually wanted to enhance dpkg to
better understand what was going on. If dpkg wanted to support
diverting directories, it would now also need to support these kind of
fake protective diversions.
* I specifically withdraw my concerns about changing debootstrap to move
directories and create symlinks after the initial unpack. I was
imagining that the complexity would be similar to usrmerge. But as
you point out in your patch, removing the atomicity requirement makes
things far simpler.
* I think I still prefer 3B to 3C if only because it might avoid M-4
(and I think M-8 might be less problematic than M-4 at least if we can
avoid protecting directories with M-8).
However, if we were voting I'd rank both 3C and 3B above none of the
above. I'd rank "let the people doing the work decide" well above
either 3B or 3C.
If there is anything else I can do to help put bootstrapping behind us at
least for now and help get to a concrete proposal for canonicalizing
files, let me know.
I think that proposal will require as much review as we can get.
--Sam
signature.asc
Description: PGP signature
