On Tue, 2021-07-27 at 13:23:46 -0400, Calum McConnell wrote: > > Of course, having to unnecessarily add more maintainer scripts to > > handle something that dpkg can do perfectly fine on its own > > TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg,
In my mind that's "false", but whatever yes… given that the reversion does not appear forthcoming, other new features might indeed be needed in case people do not want to be forced into this train wreck in slow motion. And as I mentioned on my first reply in this thread I'm prepared to devote any necessary volunteer time to implement such things in detriment of other Debian work if necessary. > and since the quote above seems to indicate you'd be willing to do that, > why not just change dpkg to support aliased dirs? I've mentioned this multiple times now, firstly because I think it would still be a broken layout. Secondly, because there are different types of dpkg features, some can be used right away, some others will still need at least two release cycles to be usable. The features that I think might be needed to be able to avoid being forced into using merged-usr-via-aliased-dirs, such as registering arbitrary files are of the former category. The features that would be needed to add support for merged-usr-via-aliased-dirs would be the latter. > Another way forward is to transition existing systems without merged-usr > to a merged-usr-via-symlink-farms. To accomplish this, we need the > ability to create symlinks in installations that are not usrmerge, but to > not create those links in installations that are. That requires either > maintainer scripts or a change to dpkg. You just criticized maintainer > scripts, so I would assume that they are not your favorite solution. Having to add maintainer script usage would be non-ideal, but would be better than being forced to use merged-usr-via-aliased-dirs. > Furthermore, others have pointed out that essential packages need to work > before maintainer scripts are executed. This behavior is codified in > policy: > > "Since dpkg will not prevent upgrading of other packages while an > > essential package is in an unconfigured state, all essential packages > > must supply all of their core functionality even when unconfigured". That's not what policy says. "unconfigured" does not mean that *maintainer scripts* have not been executed. > In other words, using maintainer scripts to create the symlinks that > enable the core functionality of these packages during configuration is a > no-go without a revision to policy and a change to dpkg (which might be > impossible). That means the symlinks would need to be included in the > package declaratively: but simply shipping them would break the existing > merged-usr installations. We've already established that un-merging and > then re-merging every installation isn't going to happen: so we'll need to > get the file references in place using a method that isn't shipping two > aliasing files and doesn't require maintainer scripts. This is based on an incorrect premise. In addition, as I've also said elsewhere bootstrapping is outside the realms of debian-policy anyway. > Simply modifying dpkg to automatically produce symlinks from /bin to > /usr/bin at unpack time is not enough either: dpkg isn't necessarily the > tool doing the unpacking, and so other tools would need to be modified, > each one of them checking for a merged-usr and then accounting for it if > needed. This solution is actually viable: it would lead to a working > system, and not break the essential guarantee. This is still based on an incorrect premise. And even though I'd find what you propose to be a major kludge, all bootstrappers I know of, always end up running dpkg over all .debs to do a proper installation of any possibly manually unpacked package. And not to mention that bootstrappers that support merged-usr-via-aliased-dirs have required implementing an explicit kludge for it. Regards, Guillem
