Re: merged /usr
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
Reply to: