Re: A Radical Multi-Arch Counter-Proposal
Anthony DeRobertis <asd@suespammers.org> writes:
> Proposal:
> A. dpkg will be extended to support installing two packages with
> the same name, but different ABIs, as previously proposed.
Still my favourite.
> B. dpkg will be extended to support two packages with the same name
> (as above) both owning the same file. It will only remove a file
> from the filesystem when the last owning package is removed.
Required for shared conffiles at the very least.
> C. dpkg will be extended so that if both a:ABI1 is installed and
> has "Multi-Arch: yes" set, and an install of a:ABI2 is
Mips has 3 abis but only 2 archs. An "ABI: <abi>" line would imply
"Multi-Arch: yes", no such line "Multi-Arch: no".
> attempted:
> 1. if a:ABI2 has "Multi-Arch: yes" set, proceed to install
> it as well. In case of file conflicts, use the
> md5sums[0] in the package to create co-ownership of
> identical shared files in a:AB1 and a:ABI2. If this does
> not resolve all conflicts, error out.
Care must be taken on upgrades. When a file changes thats shared both
old packages can match, both new packages match but extracting just
one would conflict.
Thats why I would try to avoid shared files apart from conffiles (they
are handled differently anyway) and doc (pick one, rename the
other). For doc I would suggest using /usr/share/doc/<package>.<abi>
for "Multi-Arch: yes" packages. Then a conflict in doc can be avoided
altogether.
> 2. if a:ABI2 has "Multi-Arch: no" set, refuse to proceed.
> 3. if a:ABI2 does NOT have "Multi-Arch:" set at all,
> attempt to install as normal without co-ownership.
If a:ABI2 has no Multi-Arch set it should provide for all abis, that
mean it includes the functionality of a:ABI1 and should cnflict.
I don't think we can make the old packages (without Multi-Arch set) to
coexist with new multi-arch packages of the same package. It will
result in a conflict in 99% of all cases and dpkg should not even try
to install.
> D. dpkg will assume a means a:DEFAULT_ABI, which is the default ABI
> on the machine. a:* means "a of all ABIs"[1] (used in, e.g.,
> conflicts). a:ABI of course means that particular ABI.
a means any ABI unless a only provides one ABI, than it mans matching
ABI and arch.
> E. Either dpkg must require a:* to all be the same version, or
> versions of a which change a common file must
> Conflicts: a:* << VERSION
I can live with enforcing the same version. The other seems to much
work. You can hardly get around changing a header file in a -dev
package with every release. Everything would end up with a Conflicts
line just in case.
> RATIONALE:
> * This will handle /usr/share/doc. We won't need any of the
> previously-proposed special behavior for
> /usr/share/doc/copyright.
Shared files make upgrades complicated and fragile. Renaming the files
in doc to not be shared (either in the package or by dpkg) is
easier. But either way would work.
> * This will allow most -dev packages to be multi-arched without
> splitting. This proposal creates no new packages.
Unless the header files differ which many have claimed they will. But
dpkg would catch that gracefully.
> * This allows packages to be slowly migrated to Multi-Arch with
> minimal work. All that is needed for the common case is to add
> the header 'Multi-Arch: yes' to the package and make e.g., amd64
> libs install into /usr/lib64. Some will need md5sums added too,
> but that is trivial.
> * Dependencies do not have to be changed for most packages.
>
> POTENTIAL PROBLEMS:
> * --purge and shared conffiles. I don't think conffiles should be
> shared, ever. Most lib* packages don't have them anyway, and the
> few that do are either special (libc) or can be split. This is
> only a small number of new packages.
With shared files the first lib installed provides the file, every
other abi getting installed or upgrades can show the dpkg "replace
conffile" dialog and the last lib purged would remove the conffile.
Where is the problem there?
> FOOTNOTES:
> 1. packages with Multi-Arch: yes must have an md5sums file.
Generate md5sum in dpkg on the fly or just compare files.
> 2. No idea if this should include ABIs that are not possible to
> install on this machine, like m68k on amd64. That must be
> thought about.
dpkg multiarch already has a subarchtable that details the
compatibilities between archs. If you have qemu installed on ppc you
could add i386 to the list of compatible archs for ppc.
a:* should honor that config I guess.
MfG
Goswin
Reply to: