Hi Sam, On Fri, Sep 24, 2021 at 08:26:16AM -0600, Sam Hartman wrote: > This seems... fragile. In order for this patch to work, you're also > asking the pam maintainers going forward to think differently about all > file accesses in maintainer scripts.
While this may be true, I don't think it actually is that much we ask here. So let's ask: What could possibly go wrong? Quite obviously, you could add DPKG_ROOT where it doesn't belong or you could miss adding it. Either failure doesn't affect native installation and only breaks our use case. I don't see much potential for other kinds of breakage. That seems relatively harmless to me. At worst, we'll be sending more patches, right? > I don't know that I'm going to be able to do that. I'm not expecting that of you and I think you shouldn't either. The belief that every package must have a single person or team responsible for it seems to be rooted deeply in Debian and you appear to share it. I don't believe in that. Consider what happens when you're not responsible for keeping DPKG_ROOT working beyond reviewing and applying patches. > Also, in my experience as a designer, that is a strong indication that > things are happening at the wrong layer. > This seems like an argument for a fakeroot-like thing, or support from > the kernel or filesystem or something, or from a library we're using for > file access. I fear you'll have to elaborate on this. If I had seen this other layer that could solve it for us, believe me, I'd have used it right away without bothering you with DPKG_ROOT. I fear that DPKG_ROOT is the only technical solution for this problem I'm aware of. > Having to pay attention to this detail at every layer seems fragile. Really, you don't get around that. It is very similar to cross compilation. In the "good old" native days, you could just call the compiler. Now with cross building, every time you call a compiler, you need to think and say whether you mean build or host. Admittedly, most build systems pick host as a default. Still, it is the same thing here: With DPKG_ROOT, you need to think which of those two systems you are referring to. Is it the one we are installing or the one we are using to install the former? There is little we can do to get around. All we can do is paint the shed in a different color, but that doesn't remove the detail we need to pay attention to. > I appreciate that you value being able to do things purely in userspace > without root. root is not the issue. Both of us figured that we can solve the rootless part in multiple other ways. > I want to stress that I haven't really been sold on that at all. That is quite evident from your mail. ;) > The compelling argument for me was architectures where qemu was not > available. Yes, that. > I also regret that I didn't see the implications of this from the > beginning. > The changes to pam-auth-update seemed less intrusive because of the > structure of the code. So maybe we need to take a step back again. I have an itch and look for solutions. Johannes presented a solution and you don't like it for reasons. That sounds pretty normal to me. Now we're looking for alternate methods to solve the problem. But none of the people I've talked to were able to draft anything that would remotely solve the use case. To me, it seems like we don't have any alternatives (besides not solving the itch). This is where it becomes a little difficult. In the absence of alternatives, maybe it is time to move forward? If we later figure an alternative, discarding DPKG_ROOT support is relatively simple. We (proponents of DPKG_ROOT) see that it makes things more difficult for maintainer scripts. For that reason our number one approach to maintainer scripts is replacing them with declarative alternatives where possible. A significant number of our patches only mentions DPKG_ROOT in the description. When expressing maintainer scripts declaratively, the DPKG_ROOT support goes into the tool (e.g. pam-auth-update) and the burden shrinks. I think this is where we're heading, but in the mean time, yes we will need DPKG_ROOT in maintainer scripts to make things work at all. So if you continue refusing our patches, can you propose any other way to move forward? Helmut
