Right now, it is sufficient to preseed debconf to disallow the usrmerge package messing with the filesystem tree outside dpkg. Managed installations usually have a ready-made method to do so.This is not really relevant, since the conversion is mandatory.
I have been asked to remove from the usrmerge package the debconf
question which asks to confirm the conversion.
Does anybody REALLY believe that it should not be removed?
Right now, it is sufficient to preseed debconf to disallow the usrmerge
package messing with the filesystem tree outside dpkg. Managed installations >> usually have a ready-made method to do so.
This is not really relevant, since the conversion is mandatory.
Yes, but the conversion needs to be performed by dpkg, because the usrmergePlease kindly stop beating this long-dead horse.
On Nov 08, Simon Richter <sjr@debian.org> wrote:
Right now, it is sufficient to preseed debconf to disallow the usrmerge package messing with the filesystem tree outside dpkg. Managed installationsThis is not really relevant, since the conversion is mandatory.
usually have a ready-made method to do so.
The CTTE stated that the only exception is "Testing and QA systems
should be able to avoid this transition, but if they do, they cannot be upgraded beyond Debian 12", and my plan is to arrange for this with
a flag file.
On Mon, Nov 08, 2021 at 12:56:49PM +0100, Marco d'Itri wrote:
On Nov 08, Simon Richter <sjr@debian.org> wrote:
Right now, it is sufficient to preseed debconf to disallow the usrmerge package messing with the filesystem tree outside dpkg. Managed installationsThis is not really relevant, since the conversion is mandatory.
usually have a ready-made method to do so.
The CTTE stated that the only exception is "Testing and QA systems
should be able to avoid this transition, but if they do, they cannot be upgraded beyond Debian 12", and my plan is to arrange for this with
a flag file.
As I see it the CTTE decision effectively allows the transition to be deferred until the moment you want to upgrade to 13.
So, wouldn't it make sense to go with an (extreme) low priority debconf question defaulting to 'yes, convert now' which [I think] non-experts
aren't bothered with and users/systems wanting to opt-out for the moment (like buildds) have a standard way of preseeding rather than inventing a homegrown flag-file and associated machinery?
As a bonus, if I had previously decided to forgo the automatic
transition for whatever reason (lets say to test build packages on that
box) I also have a standard way of triggering the conversion by calling dpkg-reconfigure on usrmerge at leisure before the 13 upgrade.
As I see it the CTTE decision effectively allows the transition to be deferred until the moment you want to upgrade to 13.
I think you mean: until the moment you want to upgrade to testing after Debian 12 release day. That's not Debian 13 *yet*, although you could
So, wouldn't it make sense to go with an (extreme) low priority debconf question defaulting to 'yes, convert now' which [I think] non-experts aren't bothered with and users/systems wanting to opt-out for the moment (like buildds) have a standard way of preseeding rather than inventing a homegrown flag-file and associated machinery?
Speaking only for myself and not for the TC, I think a debconf question
would be OK as an implementation of this, but the debconf question should indicate that the result of opting out is an unsupported system.
I had intended this to be for the class of systems that you would expect
to discard and re-bootstrap rather than upgrading (chroots, lxc/Docker containers, virtual machines, etc. used for autopkgtest, piuparts, reproducible-builds, etc.), where a way to undo the opt-out isn't really necessary because the system is treated as disposable.
I'm worried that by saying that unmerged is still supported in 12, we open a can of worms and just punt this down to yet another release cycle.
E.g., what exactly does this mean for backports?
On Tue, Nov 09, 2021 at 08:19:40PM +0100, Michael Biebl wrote:
I'm worried that by saying that unmerged is still supported in 12, we open a
can of worms and just punt this down to yet another release cycle.
No, unmerged will not be supported in 12. Having the ability to create something does not make it supported.
E.g., what exactly does this mean for backports?
Stuff from backports is post-release, so requires a merged system.
On Tue, Nov 09, 2021 at 03:21:25PM +0000, Simon McVittie wrote:
As I see it the CTTE decision effectively allows the transition to be deferred until the moment you want to upgrade to 13.
I think you mean: until the moment you want to upgrade to testing after Debian 12 release day. That's not Debian 13 *yet*
Yes, I meant that indeed… should have used codenames after all.
Speaking only for myself and not for the TC, I think a debconf question would be OK as an implementation of this, but the debconf question should indicate that the result of opting out is an unsupported system.
Sure.
(Minus that for 12 it is technically still supported as long as it
remains 12
(Perhaps it comes with the job as apt maintainer, but I don't "discard
and redo" systems or even chroots… upgrades until hardware failure…
my current build chroots are from 2013. So I can totally see me opt-out
first and later in… although probably more with apt_preferences)
On Tue, 09 Nov 2021 at 19:01:18 +0100, David Kalnischkies wrote:
On Tue, Nov 09, 2021 at 03:21:25PM +0000, Simon McVittie wrote:
(Minus that for 12 it is technically still supported as long as it
remains 12
No, it doesn't have to be supported, and the TC resolution explicitly
said that it doesn't have to be supported.
What *does* need to be supported is the upgrade path from 11 to 12,
or from current testing (11-and-a-bit) to 12, with any ordering of apt transactions that doesn't violate the packages' dependency conditions -
and the TC's reasoning was that the simplest, most conservative, most
robust way to make sure that continues to work was to mandate that all
Debian 12 packages, individually, are installable onto unmerged-/usr
Debian 11 (assuming that "installing a package" implies installing its dependencies, in any order that apt/dpkg consider to be valid and not breaking any dependency relationships).
(Perhaps it comes with the job as apt maintainer, but I don't "discard
and redo" systems or even chroots… upgrades until hardware failure…
my current build chroots are from 2013. So I can totally see me opt-out
first and later in… although probably more with apt_preferences)
For full systems that are managed as full systems ("pets" in the cattle
vs. pets terminology), sure, do that; the Debian installation I'm typing
this into has been copied from several older machines. However, deferring
or avoiding the merged-/usr transition on these systems is not intended
to be something that is considered valid for bookworm.
"Marco" == Marco d'Itri <md@Linux.IT> writes:
I'm sorry, but I think the only way in which that horse is dead is thatIndeed, because the sides of this argument are like three people (one of
no one has proposed patches to dpkg.
On Nov 10, Sam Hartman <hartmans@suchdamage.org> wrote:
I'm sorry, but I think the only way in which that horse is dead is thatIndeed, because the sides of this argument are like three people (one of
no one has proposed patches to dpkg.
them being the dpkg maintainer) versus everybody else.
Since some significant work on dpkg is reasonably not forthcoming then
this is clearly not a viable transition method.
David Kalnischkies wrote:
As the transition hasn't started everyone not already merged is currently deferring it. That is true for those who upgrade daily as well as for
those people who seemingly only upgrade their sid systems once in a blue moon. So, at which point have all those systems stopped deferring?
I think the logical answer is that you're "deferring" in this sense if
you are using the suggested flag file or whatever other mechanism to
prevent the merge. Until you do an upgrade which would perform the
merge without use of such a mechanism, your system is just out of date,
not deferring.
So presumably it is valid for packages to gain dependencies which force
merge or "deferring" state on installation.
On Nov 10, Sam Hartman <hartmans@suchdamage.org> wrote:
I'm sorry, but I think the only way in which that horse is dead is thatIndeed, because the sides of this argument are like three people (one of
no one has proposed patches to dpkg.
them being the dpkg maintainer) versus everybody else.
Since some significant work on dpkg is reasonably not forthcoming
Marco d'Itri <md@linux.it> wrote:
Since some significant work on dpkg is reasonably not forthcoming
Yeah, because _you,_ Marco, prefer to spend your time trying to
gaslight the project into thinking there isn't a critical-severity
bug in usrmerge. This could have all been over by now if you had
rolled up your sleeves and written the necessary patches for dpkg
when Guillem originally notified you of the problem (in 2016;
#848622; the bug log does not reflect the actual severity, but again
that appears to be all on you).
I'm not sure he has the skill or experience enough to submit a patch to
dpkg. Complaining is much easier than proposing something constructive.
Hi Svante,
On Thu, 2021-11-11 at 23:22 +0100, Svante Signell wrote:
I'm not sure he has the skill or experience enough to submit a patch to dpkg. Complaining is much easier than proposing something constructive.
I would like to remind you that Debian expects somewhat decent behavior
of contributors. Please see https://www.debian.org/code_of_conduct
Ansgar
may I also remind participants in this thread that according to our Constitution (2.1), no project member is obliged to do work on
anything they don't want to
[The bug where files disappear from packages upon being moved from
/bin to /usr/bin or vice versa, after / is a symlink to /usr] to the
best of my knowledge has not been actually observed in the wild
despite this setup being the default for 100% of Ubuntu users who install/upgrade to 21.10, 100% of new Ubuntu installs since ~2018
and an unspecified number of Debian installs being the default in
our installer too for the past two stable releases
I dare say it would help their cause a great deal more, instead of
rekindling flame wars on a mailing list,
Zack> The existence of the bug is not in question. A step-by-step"Zack" == Zack Weinberg <zack@owlfolio.org> writes:
"Marco" == Marco d'Itri <md@linux.it> writes:
The question is whether we ever get to a place where people can update
files in a package currently installed to /bin/foo and instead install
them to /usr/bin/foo.
We have a consensus that dpkg bugs make that a bad idea.
Zack> Therefore: either someone fixes the bug,"Zack" == Zack Weinberg <zack@owlfolio.org> writes:
Zack> or the transition will have to be canceled. It appears to me
Zack> that the tech ctte agrees with all of this.
There's a third option.
We sit around in the state where /bin is a symlink, but where you cannot
move files to /usr paths in the package system until the bug is fixed.
I.E. I don't think the transition is going to get canceled; we're too
far down that path.
"Zack" == Zack Weinberg <zack@owlfolio.org> writes:
"Sam" == Sam Hartman <hartmans@debian.org> wrote:
"Zack" == Zack Weinberg <zack@owlfolio.org> writes:
There's a third option. We sit around in the state where /bin is
a symlink, but where you cannot move files to /usr paths in the
package system until the bug is fixed.
I don't like that outcome either.
I think that we have reasonable mitigations for the specific problem you describe.
In particular, we do as I understand it have QA plans to build both with merged /usr and without prior to bookworm to catch problems like the
ones you describe.
After bookworm releases it's totally fine if programs reference
filesystem paths like /usr/bin/bash, so long as they don't move where things get installed.
I.E. I don't think the transition is going to get canceled; we're
too far down that path.
I don't think we would find people to do enough testing to
validate that was a reasonable thing to do. But also, the usrmerge proponents get most of what they wanted even if we're stuck in the
middle.
I want to reiterate that the initial process surrounding usrmerge was horrible. The dpkg maintainer had what turned out to be legitimate concerns that were not reasonably addressed. I think that's in part because they were presented poorly and in part because people didn't...
want to hear them. That's a real process failure.
I think people on both sides were unwilling to listen to each other.
We don't want a community where you can get your way by ignoring legitimate objections.
However, I think it was the responsibility of the developers of usrmergeAt least for this email, I'll stipulate to everything above.
to find out how bad that problem actually was, rather than dismissing it. And, as it has proven to be a genuinely critical problem, it is also their responsibility to fix it, per the 'no one can be forced to do anything' rule.
Am 17.11.2021 um 19:57 schrieb Sam Hartman:
The question is whether we ever get to a place where people can update
files in a package currently installed to /bin/foo and instead install
them to /usr/bin/foo.
We have a consensus that dpkg bugs make that a bad idea.
Is that really so? If I'm not mistaken, the problematic part was
moving files from / to /usr and at the same time moving files between packages. So doing that at the same time can be problematic. If that
would affect many packages is another question.
AIUI simply moving files from / to /usr within the same package is not problematic.
And, as it has proven to be a genuinely critical problem, it is also theirNo, it has not.
On Nov 18, Zack Weinberg <zack@owlfolio.org> wrote:
And, as it has proven to be a genuinely critical problem, it is also theirNo, it has not.
[merged /usr] is the default. It has been the
default for multiple releases of multiple distributions. All Ubuntu installations that were not using this default are now forcibly
converted upon upgrade to 21.10.
And yet nobody has actually seen [the file disappearance bug]
happen, to the best of my knowledge.
On Nov 18, Zack Weinberg <zack@owlfolio.org> wrote:
as it has proven to be a genuinely critical problemNo, it has not.
[merged /usr] is the default. It has been the
default for multiple releases of multiple distributions. All Ubuntu installations that were not using this default are now forcibly
converted upon upgrade to 21.10.
And yet nobody has actually seen [the file disappearance bug]
happen, to the best of my knowledge.
On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
Luca Bocassi wrote:
[merged /usr] is the default. It has been the default for
multiple releases of multiple distributions. All Ubuntu
installations that were not using this default are now forcibly
converted upon upgrade to 21.10.
And yet nobody has actually seen [the file disappearance bug]
happen, to the best of my knowledge.
I already explained why that doesn't prove the bug is a non-issue.
To the contrary; it means there is an enormous installed base of
systems where the bug is latent, waiting to cause problems under
conditions which we can reasonably expect to occur shortly after
the release of bookworm. Please do not make me repeat myself.
zw
I'm afraid you have not. Why would the release of bookworm make any difference? There will be nothing new that hasn't already been
happening for years.
[P]eople aren't doing the package changes that trigger the bug, yet.
They can't, because that would break systems where /usr hasn't been
merged. If the bug is not fixed I expect it will start causing
problems in unstable *after* bookworm, since (as I understand the
current transition plan) bookworm+1 development is the earliest that
package maintainers may assume /bin is a symlink.
Are you seriously claiming that that phenomenon is not a severity:critical bug?I am seriously claming that whatever you are referring to, if true, is
* to date, package maintainers have not yet begun moving
already-packaged files from / to /usr/ (specifically because doing so
would break systems that have not yet been migrated to merged-/usr,
and Debian has not yet declared that such systems are unsupported),
* after bookworm, package maintainers will start moving already-
packaged files from / to /usr/, and
* doing this will, in a non-negligible number of cases, trigger the
bug to manifest on systems where that package is upgraded from a
version where the move had not taken place to one where it has.
* doing this will, in a non-negligible number of cases, trigger the
bug to manifest on systems where that package is upgraded from a
version where the move had not taken place to one where it has.
Why do you claim that?
Given packages already did such moves in the last years and you claim
this happens in a non-negligible number of cases, could you please
point to some examples where this already happens in practice?
Given packages already did such moves in the last years and you claim
this happens in a non-negligible number of cases, could you please
point to some examples where this already happens in practice?
Given that these bugs are going to be utter bastards to reproduce, and
you can be sure that we'll have enough diversity in installed systems
that some people are going to manage to be sufficiently unlucky, it
would be nice to know the sort of damage we might expect.
It strikes me that we ought to be able to screen our own repos for
packages that could be able to tickle this bug. That would give us the
chance to look at what sorts of files we might realistically expect to
be clobbered, it should give some indication of how many packages we
should expect to be able to trigger this, and knowing this might suggest >plausible work-arounds.
On 19.11.21 11:58, Philip Hands wrote:
Ansgar <ansgar@43-1.org> writes:
My understanding is that in order to trigger this bug you need at* doing this will, in a non-negligible number of cases, trigger the
bug to manifest on systems where that package is upgraded from a
version where the move had not taken place to one where it has.
Why do you claim that?
Given packages already did such moves in the last years and you claim
this happens in a non-negligible number of cases, could you please
point to some examples where this already happens in practice?
least
to both move a file from one place to the other, and also to rename the
package that contains that file or move ownership to another package.
I suspect that you might also need to be unlucky with the order that
apt/dpkg decides to do the installation and, depending upon how far
apart the move and the rename happens, also unlucky with your choice of
from and to versions of the packages in question.
Right. I think it would be immensely useful to have an actual
reproducer so one could study the issue more closely or at least a bug report, which describes the issue in more detail, like the exact circumstances when this can happen.
So far this is merely theoretical, right?
Or do we have a documented instance of this happening?
"Marco" == Marco d'Itri <md@linux.it> writes:
On Nov 18, Zack Weinberg <zack@owlfolio.org> wrote:
Are you seriously claiming that that phenomenon is not a severity:critical bug?I am seriously claming that whatever you are referring to, if true, is
such a contrived example that does not actually happen in real life
(or at least, it does not happen frequently enough).
Is this particularly hard to fix, though?
Can't we just do something like the following pseudo-code:
(I've used /bin -> /usr/bin as an example, but the canonicalization must
deal with the other merged paths too.)
The second bit ensures that all new operations write canonicalized paths (e.g. /usr/bin/foo) into the database regardless of whether the .deb
shipped with /bin/foo or /usr/bin/foo. This ensures the database stays in sync with the filesystem moving forward.
The first bit performs a one-time canonicalization of paths in the
existing database. An on-disk flag ensures that this is run only once
(for performance reasons only, because it's already idempotent). This corrects the existing database-filesystem mismatch.
The one-time canonicalization can be removed once non-usrmerged systems
are no longer supported. The second bit needs to live (probably a lot) longer, until it's no longer reasonable to install a .deb containing non-usrmerged paths (which might be old or from a third party).
Am I missing something here?
On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
Luca Bocassi wrote:
...
nobody has actually seen [the file disappearance bug]
happen, to the best of my knowledge.
I already explained why that doesn't prove the bug is a non-issue.
To the contrary; it means there is an enormous installed base of
systems where the bug is latent, waiting to cause problems under
conditions which we can reasonably expect to occur shortly after
the release of bookworm.
Why would the release of bookworm make any difference?
On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote:
On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
Luca Bocassi wrote:
...
nobody has actually seen [the file disappearance bug]
happen, to the best of my knowledge.
I already explained why that doesn't prove the bug is a non-issue.
To the contrary; it means there is an enormous installed base of
systems where the bug is latent, waiting to cause problems under
conditions which we can reasonably expect to occur shortly after
the release of bookworm.
Why would the release of bookworm make any difference?
Up until the release of bookworm, all Debian packages must be
constructed on the assumption that they _might_ be unpacked on a
system that has not yet been converted to merged /usr. Particularly
for priority-required packages, this means that no one will be moving
files from /bin, /lib, etc to /usr in the bookworm cycle.
Post-bookworm, if nothing changes, that assumption will no longer be
in force, and people who maintain packages that install files into /
will want to simplify their packaging by installing everything in /usr instead. If they also want to change the binary packages that ships
some of those files at any point in the same release cycle -- kaboom.
I also don't understand why this isn't the correct solution. It seems >obvious to me that we should simply teach dpkg about path aliases and have+1
it update both its internal state and its processing of new packages to >canonicalize paths so that it has an accurate representation of the world, >and then ensure dpkg is upgraded first.
Are we missing something? If not, what is blocking this solution? Is it >simply a matter of someone digging into dpkg's code sufficiently to putAFAIR, Guillem has not commented on the solution when it was brought
these changes in the correct location? Or is there some other issue?
I think the main blocker at the moment is that the dpkg change *also*
has the potential to break a lot of things if it isn't carefully
designed.
From dpkg's perspective, we now (kind of) change the policy for directory-vs-symlink conflicts, which dpkg currently resolves in favour
of the directory.
But we could you know fix dpkg:-)
I'm sure that will be painful at the political level, but personally I
think it needs doing.
From dpkg's perspective, we now (kind of) change the policy for directory-vs-symlink conflicts, which dpkg currently resolves in favourof the directory. That was done in ancient times because it was somewhat
From the way dpkg and the Debian Policy are initially designed, it isobvious to me that they started out as specification documents, and only
Bootstrapping a new Debian system works by unpacking Essential packages
with ar+tar, i.e. not using dpkg. These packages will always be unpacked
to the file names listed inside the packages.
Dpkg has an elaborate per-file tracking to recover from errors, and this change introduces several new states and transitions,
That is the goal, yes, but this is a massive undertaking.
We already have a quick hack for usrmerge support in dpkg, which is the
check that allows moving a file from /bin to /usr/bin within the same
package without the file being deleted in the end (because deletions are processed last for obvious reasons), and the obscure rule is precisely
the limitation of this hack.
(I've used /bin -> /usr/bin as an example, but the canonicalization must deal with the other merged paths too.)
The second bit ensures that all new operations write canonicalized paths (e.g. /usr/bin/foo) into the database regardless of whether the .deb shipped with /bin/foo or /usr/bin/foo. This ensures the database stays in sync with the filesystem moving forward.
The one-time canonicalization can be removed once non-usrmerged systems
are no longer supported. The second bit needs to live (probably a lot) longer, until it's no longer reasonable to install a .deb containing non-usrmerged paths (which might be old or from a third party).
Are we missing something? If not, what is blocking this solution? Is it simply a matter of someone digging into dpkg's code sufficiently to put
these changes in the correct location? Or is there some other issue?
It seems like a huge waste of resources to me to do archive-wide package inspection to try to find patterns that might cause problems, and to ask
all maintainers to remember this rather obscure rule, when we could just
fix dpkg to make the problem go away.
Well, bootstrapping a new Debian system involves running a tool that bootstraps a new Debian system. I think you're constraining the problem
too much.
It's a nice property that everything on the system comes straight from a Debian package, but it's not a strict requirement, nor is it currently generally the case (maintainer scripts do things, for instance). Those symlinks are very special from a dpkg perspective; dpkg needs to refuse
to mess with them even when upgrading a package that provides them,
which would mean some irritating special-casing I suspect. It's not
clear to me that shipping them as tar members of a package is the right
way to go, as opposed to creating them separately as part of early
system configuration.
If you replace "rewrite /lib64 to /usr/lib64" with "rewrite /lib64/* to /usr/lib64/*", then this can easily be avoided.
Talking about "special casing" in dpkg is bothering me for a while. And
there is a relatively simple way to avoid any kind of special casing:
move the information out to a configuration file (which would _not_ be a conffile) - and now the code has no special casing, just
configuration-driven logic.
This new configuration file could be shipped by base-files itself, to
ensure it does not get out of sync with the filesystem structure shipped
in base-files. Then base-files' postinst would more or less need to
include the current usrmerge package, plus whatever is needed to convert dpkg's database.
This new configuration file would not be consumed by dpkg directly when installing packages, but only when the database conversion is called,
and dpkg would keep an internal list of the rewriting rules which are
active. Doing so would allow enforcing rewriting rules can only be added
but never removed, which would avoid potential issues if base-files gets downgraded.
The drawback here is that dpkg is going to rewrite all paths like /lib64
to /usr/lib64, which would naively *also* apply to the base-files
package when it looks at that package, but that can't be allowed because
now we're back to the situation where dpkg's state database is
inconsistent with the file system and dpkg thinks that base-files
contains some nonsensical /usr/lib64 to /usr/lib64 symlink.
I think in this approach there would need to be some special-case code
directly in dpkg that recognizes the usrmerge symlinks [...]
That would make it akin to dpkg
--add-architecture, which feels like a good model (although as you mention
I don't think we want --remove-architecture).
* Create a new essential package that contains these symlinks and that
needs to be unpacked before any binaries are executed in the target file
system. This has many of the advantages and drawbacks of the approach
of putting the symlinks in base-files, but may make it easier to handle
the upgrade problem. Ideally an upgrade would then involve installing
usrmerge, letting it run, and then installing this new essential package
so that it takes over ownership of those symlinks.
This still feels kind of complex and messy to me, but maybe less so.
* Create the symlinks directly in the bootstrapping script. In other
words, after unpacking base-files, the bootstrapping script would
directly create the required symlinks in the target file system, before
unpacking any other package.
This has the obvious drawback of moving things outside the packaging
system and creating a new special case that every bootstrapping script
needs to be aware of (and I know we have at least four or five that
would need modifications). It has the advantage that the usrmerge
symlinks are now not in the dpkg database and thus not subject to
rewriting, and therefore won't need to be special-cased. However, that
comes with the obvious disadvantage that they're not in the dpkg
database, so for instance dpkg -S /lib wouldn't find that symlink unless
it was added as some sort of dpkg-query special case (which doesn't seem
like a great idea).
The advantage of this approach is that it closely mimicks what's already
happening now with the usrmerge package, and for which we therefore have
a lot of existing experience.
Please don't. Since 2014 it is possible to create a Debian chroot
without taking care of the unpack order and without running any special
setup beforehand that cannot be put into apt or dpkg itself (like
creating /var/lib/dpkg/info which is not needed anymore since dpkg
1.20.0). One of my biggest motivations in writing mmdebstrap was to get
rid of all the quirks that currently live in debootstrap, move them into
apt and dpkg so that we end up with a declarative bootstrap process that
is driven by the package contents, their metadata and maintainer scripts
but does not need magic from the outside other than standardized
interfaces. Requiring the merged-/usr setup to be done by the bootstrap script would be a step backwards.
Options to make path A an alias for path B would be a lot like --path- exclude in that they really only make sense in a configuration file in /etc/dpkg/dpkg.cfg.d, although for symmetry they would presumably also
have to exist as command-line options just like --path-exclude does.
# in /etc/dpkg/dpkg.cfg.d/merged-usr
path-alias=/bin=usr/bin
path-alias=/lib32=usr/lib32
path-alias=/lib64=usr/lib64
path-alias=/lib=usr/lib
path-alias=/libo32=usr/libo32
path-alias=/libx32=usr/libx32
path-alias=/sbin=usr/sbin
So I do not think there should be a command-line option for this; unless
it would behave like `--add-architecture` and register the setting
somewhere.
I do not think this should be a configuration file (unless you suggest supporting other values or removing individual lines; after all a configuration file exists to be changed).
Zack> Maybe it was not obvious to anyone in 2016 that the package"Zack" == Zack Weinberg <zack@owlfolio.org> writes:
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 211:38:33 |
| Calls: | 6,619 |
| Calls today: | 1 |
| Files: | 12,168 |
| Messages: | 5,317,311 |