Re: A Radical Multi-Arch Counter-Proposal
On Jan 16, 2004, at 07:12, Goswin von Brederlow wrote:
Anthony DeRobertis <asd@suespammers.org> writes:
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.
Truthfully, I'm worried about shared configuration files. That mess
seems hairy.
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".
I think I'll rename this line to 'Coalesce: no' (to prohibit it) or
something like that.
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.
Well, since we're working off the md5sums file, this is fairly easy to
check before doing any unpacking. If you find it won't work, then tell
the user the two packages he has tried to install conflict, and error
out. If it does work, mark the packages half-unpacked and start
unpacking.
Of course, for values of "fairly easy" ranging from "untrained monkeys
to do this" to "with this much work, could of made the dang thing
sentient." I guess that means I've volunteered to find out....
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.
Naming that 'Multi-Arch' in my original proposal was not a good idea.
Maybe the ABI tag could be used for this (or isn't it already?). If I
remember correctly:
ABI: strict # provides for this ABI only
# otherwise, provides for all compatible ABIs
If that's correct, those terms seem a little confusing --- why not list
the ABI names it provides for, or 'all'? I think that might even make
bootstrap easier, by just assuming a package that doesn't have an ABI
line is traditional ABI of that architecture. So all the i386 packages
would assume ABI: i386.
I think that 'can be installed along with other packages of the same
name' and 'supports which ABIs' are different, and should use different
fields.
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.
I bet I can get most lib packages to work without trouble. That's what
I'm hoping, at least. Probably even lib-dev ones as well.
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.
I think we're saying essentially the same thing.
If a provides all ABIs, then (to me) a clearly satisfies a Depends: on
a:foo or a:bar or a:whatever.
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.
I'll go with same version, then. We already require same version for a
package to propagate to testing, anyway.
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.
I think otherwise; the only way to find out is to try. Which, by
proposing, I suppose I have volunteered myself for.
Renaming the files
in doc to not be shared (either in the package or by dpkg) is
easier. But either way would work.
Well, renaming all those files, splitting packages, etc. might be
doable for sarge+1. I think it's quite an uphill battle (especially
splitting that many packages). That requires touching a lot of
packages. We could probably have a stable amd64 in three years, when
sarge+1 releases.
I'm hoping to be able to do it with minimal changes to sarge, so we
could at least have an unofficial stable add-on to sarge in a year or
so.
* 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.
Yes, that's correct. I hope most dev packages can have their header
files coalesced. But for the few that can't, hopefully having them
conflict (or just being Coalesce: no) will be no big deal.
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?
On amd64, we'd be asking about replacing each conffile twice. On mips,
apparently three times.
Technically, there is no problem. Practically, the lynch mob disagrees.
FOOTNOTES:
1. packages with Multi-Arch: yes must have an md5sums file.
Generate md5sum in dpkg on the fly or just compare files.
That requires unpacking first. An md5sum file compare is MUCH quicker,
especially since that is part of the control archive.
Reply to: