On Wed, 2022-09-28 at 09:51 +0200, Helmut Grohne wrote: > Hi Luca, > > As much as I agree with you on other matters... > > On Tue, Sep 27, 2022 at 09:11:18PM +0100, Luca Boccassi wrote: > > baseless, patently false statements - I frankly find it quite upsetting > > to see claimed that "we have refused to fix any bug" as a self-evident > > fact, when even a cursory look at the distribution packages/bugs > > trackers in the past couple of months tells a very different story. > > This is not as clear cut as it may seem and we have disagreed on this > before. In earlier days, we had multiple disagreements about whether > something actually is a bug. And when it came to fix dpkg-shlibdeps, > there clearly was a lack of action until Raphael and Guillem handled the > matter in despair. I agree that the broad accusation is distant from the > truth. Recent history has a lot of quick responses and fixes even in > the face of inappropriate communication styles used by others. However, > when the thing to touch is dpkg, I think refusal is the right term. > Admittedly, you do have reasons to refuse, but that's still refusal. We > keep these bugs (whose severity we disagree about) and have mitigations > and workarounds for them in place. > > This is a niche aspect of the whole matter. I think it deserves > correction, but it doesn't change the broad picture that there are > little news in this report that would change the CTTE evaluation of the > matter.
Adding mitigations, workarounds and enhancing our test suites to detect possible issues in my book does count as working on it. It might not be some people's preferred form of contribution, but on the other hand there's no universal law of physics demanding that everything needs to be fixed to the complete satisfaction of any and all passerbys. Also, none of you are paying my salary ;-) Could the mentioned issues happen before? Maybe. Can they happen now, after the work that has been done? No (again to the best of my knowledge, reproducers that can fly undetected are always welcome). Ignoring this does not strike me as a good way to start a conversation, much less to make demands (not referring to you, obviously). > There also is one more recent disagreement that keeps popping up here > and there. We used to have a bootstrap sequence that did not require > auxiliary setup code. Initially, the transition was deployed by usrmerge > and all was fine from a bootstrap point of view. Now with usr-is-merged, > this interface is broken. From my point of view, this is a significant > regression and when I've been discussing this with proponents, the > reaction could reasonably be described as refusal to recognize the > existence of a problem. I fear we need to revisit this at some point. > The transition is also not complete until that auxiliary code is gone. This will sound like a long-winded rant but please bear with me. In modern OS design the end goal has to be that vendors ship under /usr and optionally /etc (see the concept of hermetic /usr and/or /etc). Everything else happens at the moment a system is instantiated. And that does not only include directory layout like /var, /root, /home and so on - which cannot and must not be shipped by packages to make this work - but it _must_ include setting up security mechanisms such as encryption and attestation. Linux is woefully and embarassingly behind Windows and OSX on the security front these days, and it's a shame because for a long time we were so far ahead. For starters, we need to move toward transparent and automated encryption (and much more) by default or we will keep falling behind, and we can't live forever off the meme that "Linux is more secure by default" when that is patently not true anymore, because at some point the zeitgeist will catch up. The key point I want to put across is that the idea that you can get from zero to a working, finalized system _exclusively_ by installing packages is not something that is fit for the modern world of computing. You should of course be able to create an atomic, hermetic vendor tree (/usr) just by installing packages. My hope is that with bookworm+1 we will be in a place where no packages install anything under /bin, /sbin and /lib*, and everything has moved, so that we will be in that place again. How we will get there, well, there's a few options - one thing at a time. > In the end, we probably agree to disagree on what it means to have this > transition finished. I expect that from your point of view, the > transition is now finished given that init-system-helper forces the > migration. I very much disagree that we're done. The question now is who > will do the work to finish it and who will refuse to do that work? At the cost of sounding like management - depends on your definition of "finished". My top-priority goal is that from bookworm onward we can assume and take for granted that all systems are converted and we do not have to keep supporting both states anymore. As hinted above that is not the end of it, just the starting point. How and what that looks like is up in the air, but the key point is that it is not tied to the current effort. And also as always, this is open source: literally anybody is free to come up with any solution they like to that perceived issue, at any time, there's nothing stopping anybody from doing any work, as long as it doesn't conflict with the current efforts and goal - which is a very low bar. Anybody could work on this in parallel, it's not either/or. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
