Re: Migration path for 'Multi-Arch:allowed' packages
On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert <firstname.lastname@example.org> wrote:
> In particular, I filed a bug against dpkg requesting that it produce
> more informative error messages in these cases , but I wonder if a
> part of the solution shouldn't be more automated or at least presented
> at a higher level through apt/aptitude, etc?
Chicken or the egg?
You need to upgrade to support MultiArch,
but you need MultiArch to upgrade…
(beside, how would the detection for such a message look like?)
In theory, the correct thing would be to ignore MultiArch for wheezy
and only do such things for wheezy+1, but in reality this doesn't
seem to be too desirable, so lets see first what the situation is
(as I and probably others are not to deep into wine [packaging]):
Looking at src:wine debian/control  suggests that the plan is to
provide only 32bit packages expect for the package 'wine' which
depends on the 32bit packages (wine-bin specifically) implicitly
as it is marked M-A:foreign and not available for other archs.
apt/squeeze as it doesn't have the needed information for
32bit packages (on an 64bit system like amd64) will either decide
to held or remove the package wine (depending on which and how
the package blocks other package upgrades).
Beside that uncertainty isn't great this isn't very discoverable for
a user between all actions done to the system.
Maybe all maintainers who want to use Multi-Arch now in wheezy
(and therefore drop amd64 packages) should get together and write
a "what to do after the distribution upgrade" for the release notes,
a (low priority) debconf message and if you want to be really fancy
a "transitional" package which shows the same text in case the
"dropped" binaries are executed.
> Also, limitations in the existing testing migration tools are making
> wine not considered for wheezy, since those tools don't check whether
> dependencies for 'Multi-Arch: allowed' packages are satisfied by
> packages on other architectures.
Please reread the Multi-Arch spec and the various wiki pages.
This is NOT what "Multi-Arch: allowed" indicates.
This flag is only for very special packages like python …
There is no flag to indicate that a dependency can be from a
foreign architecture - this information is already provided
by the package you depended on (M-A: foreign).