Hi Guillem, >These directories are included because the package should be >self-contained and ship all required parent directories, otherwise >dpkg would fail to unpack as you mentioned (even though there's
right. >generally the Essential set in play), and so that the directory >"ref-counting" (as a shared resource) works and the last package >shipping it that gets removed/purged (regardless of the order) can >properly remove all owned entries. Also for «dpkg -S»'s sake. If I omit just the top-level directories (bin, etc, usr), these things all still work (see my previous message), and I specifically tested dpkg -S both on unmerged bookworm (a buildd chroot, hence unmerged) and merged sid (chroot). >> Hmh, lintian warns, and dpkg needs the directories present if >> not in the .deb, but most likely we c̲a̲n̲ skip top-level dirs. > >It looks like you went in this direction for the packages in Debian. No, I have not uploaded anything yet. I only attached as experiment… https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1073608;filename=mksh_59c-38_amd64.deb;msg=39 … to this bugreport, for inspection by Helmut and others to see whether this approach will suffice as I refuse to introduce trouble for users by moving the files around. Could you please have a look at it, compared with 59c-37 in sid, to see whether this would work for you? My tests indicate so. Directory refcounting is not a problem as a package that does not ship say /bin in its data.tar can create a symlink in /bin/ as part of the maintainer scripts. The top-level directories are Essential. >But I'd ask you to please stop doing that, as I consider this to also >be breaking dpkg assumptions. And as part of the filesystem metadata Huh, then we’re at an impasse… although, again, the implicit “base-files has to be extracted first” with base-files containing the /bin symlink will suffice for any normal operation, and as to Helmut saying that “dpkg-deb -x” will cause problems, I’ll have to defer this to you as dpkg maintainer to fix. >In the future my plan is to add a special dpkg filesystem metadata type […] That’d be good, except… >parent). So the data.tar would contain /usr/bin/<something>, the package … no, data.tar should still be able to contain /bin/<something>. The CTTE decision for the installed OS to be usrmerged has no bearing on individual packages’ layout after all, and the .deb files could conceivably also be used on nōn-usrmerged systems, so this entire “fun” needs to be done outside of packages (other than base-files and the Essential set, of course). bye, //mirabilos -- <diogenese> Beware of ritual lest you forget the meaning behind it. <igli> yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
