Hi, Quoting Guillem Jover (2024-05-14 10:24:09) > When I proposed suppressing the creation of the symlink I had in mind and had > locally the first approach, because it's less noisy, and I assume users on > those kind of systems will have logic somewhere to handle that case anyway.
sure, works for me! Thank you! :) > But I've been thinking that this still seems wrong from a conceptual PoV, in > that I think base-files should be unpacked as one of, if not the first > package as part of the bootstrapping protocol, as it encodes the structure > and metadata for the base filesystem. I think next would be base-passwd as > that also defines the metadata for the filesystem. > > For example the symlink to dir and dir to symlink avoidance behavior > in dpkg would be one reason for this, another is that directory > metadata does not get updated if the directory exists, so the first > unpack wins. > > I realize that we have continuously talked about wanting to avoid > encoding this kind of ordering in external tools, and this information > should be part of the packages themselves (which I still think is the > right approach). But I think we still could extend the packaging > and/or possibly the bootstrap protocol to cover this case. > > One option would be to add dependencies within the bootstrap set on > both of these packages, but that goes counter to the no-depends on > essential packages, and would not be safe against other external > packages that might conflict with metadata definitions in base-files, > but it would work for the specific dpkg issue, and perhaps that would > be the better immediate fix. Another could be to mark these two base-* > packages somehow so that the bootstrap tools know in a generic way > that they need to unpack them first. I guess a field could be used, > something like the following comes to mind: > > base-files > Bootstrap: fsys-tree > > base-passwd > Bootstrap: fsys-meta > > (or Bootstrap-Phase or Bootstrap-Order, or …). > > Where I think the order should be: > > fsys-tree → fsys-meta → rest of essential + dependencies > > This does not solve the other bootstrap problem we've had in the past > with base-files requiring passwd information from base-passwd before > that has been unpacked, but I guess that might partially go away once > we can declare optional paths and template-based initialization > through fsys metadata so that the base-files maintscript can disappear > completely. Although an external dpkg will still have a similar problem > as base-files currently does, and will need to either assume some name > to id mappings or use the ones from outside the chroot, but meh. > > (But perhaps the solution to that last bit is for base-files to declare > the user/groups it requires as dpkg sysusers out of previously agreed > definitions from base-passwd, then that would make it all self-contained.) Please note that the issue I encountered was *without* base-files installed so this issue only exists in completely unsupported situations. Thus I think that the fact that you now added support for it is not an argument for needing dependencies between essential:yes packages. Personally I prefer a new field over hard-coding package names but I prefer even more not needing either of those. You gave the example of base-files needing information from base-passwd and while this is correct, this dependency can be avoided by hardcoding the needed information from base-passwd into base-files at build time. I think helmut has proposed that in the past. Thanks! cheers, josch
signature.asc
Description: signature
